You can enable {% data variables.product.prodname_code_quality_short %} for a single repository, or for every repository in an organization at once. Enabling at the organization level gives all your teams a consistent quality baseline with a single change, while enabling per repository lets you target specific projects or roll out gradually.

• An enterprise owner must have allowed {% data variables.product.prodname_code_quality_short %} in your enterprise. See AUTOTITLE.
• {% data variables.product.prodname_actions %} must be enabled because {% data variables.product.prodname_code_quality_short %} uses actions to run each {% data variables.product.prodname_codeql %} analysis.
• To get the full benefit of the feature, your repository should include one of the languages supported for quality analysis by {% data variables.product.prodname_codeql %}. See Supported languages.

{% data reusables.repositories.navigate-to-repo %} {% data reusables.repositories.sidebar-settings %}

1. In the sidebar, under "Security", click {% data variables.code-quality.code_quality_ui_settings %} to display the "{% data variables.code-quality.code_quality_ui %}" page.

2. Click Enable code quality.

3. Review the information on the Code quality page:

   • Languages: If you want to disable {% data variables.product.prodname_codeql %} analysis for any of the languages, clear the associated check box.
   • Runner type: If you want to use a different runner, choose Labeled runner and define the Runner label. See AUTOTITLE and AUTOTITLE.

4. Click Save changes to save your configuration for {% data variables.product.prodname_code_quality_short %}.

If your organization has configured caching of private registries, these will be available for code quality analysis to use to resolve dependencies. See AUTOTITLE.

At the organization level, you control {% data variables.product.prodname_code_quality_short %} with a single Repository access setting. This gives you granular options, from enabling every repository to targeting a specific list or a dynamic filter, so you can pilot {% data variables.product.prodname_code_quality_short %} intentionally and roll it out at your own pace. Repositories within your selection are enabled, and repositories outside your selection are disabled.

For the available access options, and how filtering and enforcement work, see AUTOTITLE.

{% data reusables.organizations.navigate-to-org %} {% data reusables.organizations.org_settings %}

1. In the sidebar, under "Security", click {% data variables.code-quality.code_quality_ui_settings %}.
2. Under "Repository access", select an option from the dropdown menu.
   • If you selected Selected repositories..., choose the repositories you want to enable.
   • If you selected Matching a filter..., define your filter.
3. Optionally, to prevent repository administrators from changing these settings, enable Enforce access.
4. If your change enables or disables {% data variables.product.prodname_code_quality_short %} on any repositories, a "Review enablement and billing changes" dialog appears, showing the total number of enabled and disabled repositories and the associated costs. Review the details, then click Confirm.

Your changes are saved automatically and begin to propagate immediately. In large organizations, it can take several minutes for the changes to apply across all repositories.

If you're rolling out the feature across many teams, we recommend you pilot on a small group and tune your quality thresholds before you enable everywhere. See AUTOTITLE.

When you enable {% data variables.product.prodname_code_quality_short %}, an initial {% data variables.product.prodname_codeql %} scan runs on the default branch. Weekly scheduled {% data variables.product.prodname_codeql %} scans start only after a push or pull request triggers a scan. Pushes and pull requests from before enablement do not count as activity.

Weekly scheduled scans pause if no push or pull request has triggered a scan in the last 180 days. Initial scans, scans triggered by configuration or language changes, and scheduled scans do not count as activity. A new push- or pull-request-triggered scan resumes the weekly schedule.