GitHub · Pull requests · Code quality · Checked October 26, 2026

GitHub: the merge waits for code quality results

A branch ruleset can require code quality results ("Require code quality results"). If the repository is configured with GitHub Code Quality, a pull request into that branch is then not merged while the analysis is still in progress, when the analysis fails for any reason (for example, the budget for Actions minutes is exhausted), or while Code Quality has found a result at the severity the ruleset defines or higher (GitHub's available rules for rulesets and setting code quality thresholds for pull requests). Classic branch protection has no such setting; it is the ruleset rule code_quality (checked October 26, 2026).

GET /repos/OWNER/REPO/rules/branches/BRANCH
[{ "type": "code_quality", "parameters": { "severity": "warnings" } }]

What the rule checks

One severity: the ruleset's "Severity" is the lowest severity of code quality results that must be resolved before a pull request can be merged: "Errors" blocks unresolved errors, "Warnings and higher" unresolved warnings or errors, "Notes and higher" unresolved notes, warnings or errors, and "All" any unresolved code quality results. Through the REST API it is severity (errors, warnings, notes, all), and when the rule is configured, a code quality analysis must be done on the pull request before the changes can be merged (GitHub's REST API endpoints for rules).
The labels: every finding carries a severity label. Error is a high-severity issue likely to cause bugs, failures or major maintainability risks; Warning a moderate one that may affect quality or reliability but is not immediately critical; Note a low-severity issue, minor improvement or recommendation (GitHub's preventing code quality issues from reaching your default branch).
What is analyzed: on pull requests, Code Quality posts rule-based CodeQL findings only, for C#, Go, Java, JavaScript, Python, Ruby and TypeScript; its AI findings cannot be set as a threshold, and the threshold has an effect only if the repository has code in a supported language (GitHub's GitHub Code Quality).
Coverage is another rule: a minimum line coverage or a maximum coverage drop is the separate "Restrict code coverage" rule, not "Require code quality results".
Evaluate first: GitHub suggests the enforcement status "Evaluate" while the threshold is calibrated; the ruleset insights then show which pull requests would have been blocked, and "Active" enforces it. "Get rules for a branch" returns all active rules that apply to a branch, at whatever level they are configured, and not the rules of rulesets that only evaluate or are disabled.

Where it shows on the pull request

The banner: when the changes fall below the required threshold, the "Checks" section at the bottom of the pull request shows "Merging is blocked: Code quality findings were detected." If the banner does not name a severity level, the repository requires all findings to be addressed (GitHub's resolving a block on your pull request).
The check: the analysis shows as the "CodeQL - Code Quality / Analyze" check in the "Checks" section. A failure means the workflow failed to run, for example because the budget for Actions minutes is exhausted (GitHub's CodeQL-powered analysis for Code Quality).
The findings: comments by github-code-quality[bot] on the Files changed tab, each with its severity label and a suggested autofix.
The workflow: Code Quality and code scanning runs both use the workflow name CodeQL on the Actions tab; Code Quality runs have the actor github-code-quality, or a run name such as "Code Quality: push on main."

What to do

Findings at the blocking severity: fix or dismiss every finding at that severity or higher. On the Files changed tab, click "Commit suggestion" (or "Add suggestion to batch") to apply an autofix, or "Dismiss finding" with a reason when it does not apply; a dismissed finding lets you merge, but it appears in the repository's backlog and in future pull requests. If the banner stays, a finding at or above the blocking severity is still open.
Analysis in progress or failed: give the Code Quality check time to finish; if it failed, open its workflow run's logs on the Actions tab. A ruleset that requires results while the workflow does not report on pull requests can block the merging of all of them.
No Code Quality comments: the scan may still be running, the changes may not touch a supported language, or there are no findings.
A coverage message instead: "Line coverage 22.0% is below minimum 50.0%" or "Line coverage decreased by 2.5%, maximum allowed drop is 1.0%" is the coverage rule (see a code coverage threshold blocks the merge); add or update tests and push, and the coverage check runs again.

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff, and merges it with the methods the target branch allows. When GitHub calls the pull request blocked, its merge checks name what they can read: required checks that have not reported, a review still required, unresolved conversations and unsigned commits the rules hold against it, the rule on the most recent push, and the code scanning tools the rulesets require. Its checks list shows the Code Quality check with the others, and when the branch's rulesets require code quality results, the merge checks of a blocked pull request say so and name the severity of findings that must be fixed or dismissed. The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.