Repository ruleset rule type `code_quality` is not modelled

[etifontaine]

Summary

The repository ruleset rule type code_quality is not modelled by RepositoryRule / the ruleset rule types, so it cannot be read or written through this library. It corresponds to the "Require code quality results" checkbox on a branch ruleset, which reached general availability on 2026-07-20.

API shape

GET /repos/{owner}/{repo}/rulesets/{id} returns it as a rule alongside the existing types:

{
  "id": 16352232,
  "name": "Project branch",
  "target": "branch",
  "enforcement": "active",
  "rules": [
    { "type": "code_quality", "parameters": { "severity": "errors" } },
    { "type": "copilot_code_review", "parameters": { "review_on_push": true, "review_draft_pull_requests": false } }
  ]
}

severity is the lowest severity level at which code quality results block a merge. I have only observed "errors" on the wire, so the full accepted set is worth confirming against the docs before fixing an enum — note the existing code_scanning rule's security_alerts_threshold already uses "errors" / "errors_and_warnings" style values in rules.go, which may or may not be the same vocabulary here.

Why it matters beyond a missing field

PUT /repos/{owner}/{repo}/rulesets/{id} replaces the entire rules array. Because the rule cannot be represented, any consumer that round-trips a ruleset — read, modify one unrelated attribute, write back — will silently drop code_quality and remove a merge gate, with nothing in the request or response to indicate it happened.

That is not hypothetical. integrations/terraform-provider-github builds its github_repository_ruleset resource on this library, and a ruleset carrying this rule imports cleanly, plans cleanly, and would lose the rule on the first apply that touched any other attribute of the resource. We ended up dropping the affected ruleset from Terraform management entirely rather than hold that risk. Modelling the type here unblocks the provider side (there is no provider-side workaround, since there is nothing to serialise).

Environment

• go-github: absent as of current master — github/rules.go models copilot_code_review, required_code_scanning, required_status_checks et al., and contains no occurrence of code_quality or CodeQuality
• Observed against: GitHub.com, private repository in an organisation on the Team plan

Willing to contribute

Happy to open a PR adding the rule type if a maintainer confirms the preferred shape — in particular whether severity should be a plain string or a typed constant set.

[gmlewis]

Since you have only seen "errors" on the wire, I think it is safe to use type string.