GitHub now lets teams enable and configure Code Quality on individual repositories through an API. The feature is in public preview on github.com, and GitHub says it is not available on GitHub Enterprise Server.
That sounds small. It is not, if you manage many repositories.
Until now, repository-level rollout of this kind of feature has usually meant a mix of manual setup, scripts around existing settings, or uneven adoption across teams. The new Repository Enablement API gives platform, AppSec, and developer-experience teams a direct way to turn Code Quality on or off, set the languages to analyze, choose the runner type, and read back the current configuration.
What GitHub added#
GitHub announced two new REST API endpoints for Code Quality repository setup.
The first endpoint changes configuration:
PATCH /repos/{owner}/{repo}/code-quality/setup
GitHub says this endpoint can be used to enable or disable Code Quality default setup for a repository, configure the languages to analyze, and specify the runner type.
The second endpoint reads configuration:
GET /repos/{owner}/{repo}/code-quality/setup
This returns the current Code Quality setup for a repository, including state, languages, runner type, and analysis schedule.
The important part is not only that Code Quality can be enabled. It is that the configuration is now inspectable and repeatable through an API. That changes the feature from a repository setting into something teams can wire into provisioning, compliance checks, internal developer portals, or audit scripts.
GitHub describes the API as available today in public preview on github.com. Public preview should be read literally: useful enough to test, not something to treat as frozen contract without checking the documentation and change notes.
Why this matters for real repositories#
Most large GitHub organizations do not have one clean repository model. They have old services, new services, archived code, forked experiments, mono-repos, internal tools, and projects with different language mixes. Security and quality tooling usually fails at the edges: the abandoned repo, the team that never clicked setup, the project that was created outside the normal template.
An API does not solve that by itself. It does remove one common excuse.
With repository-level enablement exposed, teams can check which repositories have Code Quality configured, compare that state against internal policy, and apply setup consistently where it makes sense. The GET endpoint is especially important here. Rollout is not only about pushing configuration. It is about knowing what is already configured, what drifted, and what should be left alone.
The runner type field also matters. Analysis is not just a checkbox; it has execution cost, performance implications, and trust-model implications. A centrally managed rollout that ignores runner choice can create operational friction. An API that exposes runner configuration gives teams a better chance to automate without flattening every repository into the same shape.
The analysis schedule field is another useful signal. If a team wants to know whether quality checks are active, stale, or aligned with expected workflows, schedule visibility matters. The changelog does not provide enough detail to say how flexible scheduling is through this API, but it does confirm that the current schedule is retrievable.
What not to overclaim#
This announcement is not an exploit story, not a vulnerability disclosure, and not proof that Code Quality is now universally deployed. It is a control-plane change.
It also does not mean every organization can use it. GitHub says the feature is available on github.com and not available on Enterprise Server. For companies running GitHub Enterprise Server, this is a clear boundary. They can track the feature, but should not plan around immediate availability unless GitHub later announces support.
The source material also does not give a complete list of supported languages in the collected text. The changelog says supported languages are included, but the provided excerpt cuts off before listing them. Do not assume language coverage from this note. Check GitHub’s documentation before using the API in rollout logic.
Public preview status is another constraint. API shape, behavior, permission requirements, and supported configuration options may still change. That does not make the feature unusable. It means teams should test it behind a thin internal wrapper or automation layer instead of scattering direct calls across many scripts.
Practical checks for teams#
If your organization already uses GitHub Code Quality, this API is worth testing first as an inventory tool, not as a mass rollout button.
Start with read-only discovery:
- list repositories that should have Code Quality enabled
- call the
GETendpoint for a sample set - compare returned state, languages, runner type, and schedule against your expected baseline
- identify repositories where setup is missing or different for a valid reason
Only after that should teams consider using the PATCH endpoint for enforcement or onboarding. A blind enablement script can create noise, unexpected CI load, or ownership problems. A measured rollout can close real gaps without turning quality tooling into another background tax on developers.
For platform teams, this API fits cleanly into repository creation workflows. When a new repository is created from an internal template, Code Quality can be configured as part of the same path that applies branch protection, secret scanning, code owners, CI defaults, and other baseline settings.
For AppSec teams, the better use may be drift detection. A scheduled job can read configuration, flag repositories where Code Quality was disabled, and route exceptions through the same approval model used for other security controls.
The larger signal#
GitHub keeps moving repository governance away from manual UI setup and toward APIs that can be managed at scale. This Code Quality endpoint follows the same direction as other enterprise-management and security-control updates in the GitHub ecosystem: more settings become addressable, measurable, and enforceable through automation.
That is the real value of this release. Not that one more feature has an endpoint. That repository quality posture can now be treated as state: read it, compare it, change it, and audit it.
Teams should still be careful. Public preview is not a stable contract, and the absence of Enterprise Server support limits where this can be used today. But for organizations on github.com with many repositories, this is a practical building block for reducing configuration drift.