Stop blocking merges on legacy SonarQube technical debt
Configure SonarQube Quality Gates to fail on new-code issues instead of blocking legacy codebases, then verify gate status in CI.
30 Mar 2026, 19:36 UTC

A red pipeline for old debt
Your pull request is ready, but CI turns red after the SonarQube scan. The Quality Gate reports ERROR not because of your diff, but because the project carries years-old bugs and uncovered modules nobody asked you to fix. The merge is blocked, and the team starts treating SonarQube as an obstacle instead of a signal.
The fix is usually not to disable the gate. It is to configure the gate so it measures what changed, not what already existed, and to verify the gate result in CI before promoting a build.
How a Quality Gate decides pass or fail
A Quality Gate is a set of conditions tied to metrics such as bugs, vulnerabilities, reliability rating, security rating, coverage, and duplicated lines. If any condition is unmet, the gate fails. SonarQube reports the result as OK, ERROR, or WARN on the project dashboard, in pull request decoration, and through webhooks.
Conditions can apply to the entire codebase or only to new code. New code is measured against a reference version or the previous analysis. That distinction matters because a legacy project often carries issues that predate SonarQube.
Pull request decoration and advanced branch analysis are commercial-edition features. Community Edition supports project analysis and gate configuration, but with more limited branch scope.
Configure the gate to measure change, not history
Open Administration > Quality Gates in the SonarQube UI. You can edit the default gate or create a project-specific gate. UI labels may vary slightly by version, but the condition model is the same. For a legacy application, start by adding conditions on new code only.
A practical condition is: metric Bugs, scope New code, operator greater than, value 0, severity ERROR. This fails the gate when analysis detects at least one new bug, while leaving pre-existing bugs alone.
Worked example: add a new-code bug condition
1. Sign in as a system administrator.
2. Go to Administration > Quality Gates.
3. Select the default gate or create a new gate, then set it as default.
4. Add condition: Bugs greater than 0 on New code, set to ERROR.
5. Assign the gate to the project, or leave it as default so new projects inherit it.
Run the analysis from a CI agent or a local machine with network access to SonarQube:
sonar-scanner \
-Dsonar.projectKey=example-app \
-Dsonar.sources=. \
-Dsonar.token=$SONAR_TOKEN
The token must have permission to analyze the project. Replace example-app and $SONAR_TOKEN with your project key and CI secret. A failed scan does not change source code, but a failing gate can block the pipeline and prevent a release.
After the scan, open the project dashboard and confirm the gate status. OK means all conditions passed. ERROR means at least one condition failed and CI should not promote the build.
Verify the gate before promoting a build
Check CI logs after the scanner finishes. Look for the quality gate status line. If your CI uses webhooks, inspect the payload for the gate result before deploying. Do not merge or release when the gate reports ERROR.
If a gate fails unexpectedly, check for missing coverage sensor data or misconfigured exclusions. These can cause false failures unrelated to actual code quality.
Trade-offs and limitations
- Strict gates on overall code can block legacy projects until old issues are fixed or excluded.
- Coverage thresholds may encourage low-value tests instead of better design if applied without context.
- Community Edition has more limited branch and pull request analysis than commercial editions.
- Gate changes take effect on the next analysis, not retroactively.
Rollback
Editing a Quality Gate changes SonarQube configuration. To revert, return to Administration > Quality Gates, remove the condition, or restore the previous default gate assignment. The next analysis uses the restored configuration.
Closing
Start with new-code conditions, keep overall conditions off for legacy code, and verify gate status in CI before promoting any build. Expand the gate gradually as the team resolves existing debt.