Quality gates

A quality gate is an indicator that tells you whether your code meets the minimum level of quality required for your project. It consists of a set of conditions that are applied to the results of each analysis. If the analysis results meet or exceed the quality gate conditions then it shows a Passed status otherwise, it shows a Failed status.

In this section, we will focus on the built-in quality gate, called Sonar way, which is available in every organization. By default, this is the one assigned to all new projects on import. For information on defining and applying different quality gates, see Setting your standards. Quality gates appear with analysis results

Quality gates appear with analysis results

Quality gates are displayed in the SonarCloud interface in conjunction with the analysis results of the main branch of the project, other non-main branches, and pull requests.

For pull requests, the quality gate will also be displayed in the repository platform as a pull request decoration.

The quality gates will indicate a Passed or Failed status (or if not properly set up, a Not Computed status, see below)

For example, go to Main Branch > Summary > Quality Gate; here you can see the quality gate for the main branch of a project with a Passed status:

If you are using the SonarLint IDE extension, changes to your main branch quality gate will also appear as notifications in your IDE (this only works if you have configured SonarLint to connect to your SonarCloud account).

Getting notified when a quality gate fails

Thanks to the notification mechanism, users can be notified when a change in the quality gate status. At this time, you must subscribe to projects one-at-a-time to receive notifications about changes in the quality gate status. To do so, subscribe to the New quality gate status notification either for each project you're interested in.

• My Account > Notifications > Notifications per project. From there, select Add a project, search for Your project, then select New Quality Gate status.
• Your Project > Information > Notifications, and select New Quality Gate status.

When is a quality gate not computed?

There are two main reasons why the quality gate may not be computed:

• You have performed only one analysis on your code (the quality gate is computed after the second analysis).
• No new code definition is set up for the project.
  This may only occur for projects created a long time ago since in the current version of SonarQube you cannot create a new project without setting up the new code definition. 

If the quality gate has not been computed then the Not computed message is displayed in the place where the quality gate status usually appears as illustrated below. 

The Set New Code Definition button is displayed as well in case no new code definition is set up. To fix this, click the button. For more details on setting up the definition, see About new code page.

How quality gates are defined

Quality gates are defined by a set of failure conditions applied to the results of an analysis. Two separate sets of conditions can be defined: one that applies only to new code and one that applies to overall code. However, failure conditions are typically applied to the former using the Clean as You Code strategy.

For example, the built-in Sonar way quality gate definition has the following conditions on new code (and no conditions on overall code):

• Coverage is less than 80.0%
• Duplicated Lines is greater than 3.0%
• Maintainability Rating is worse than A
• Reliability Rating is worse than A
• Security Hotspots Reviewed is less than 100%
• Security Rating is worse than A

If one or more conditions are true, then the quality gate is Failed. Otherwise, it is Passed.

For more details on how to manage quality gates, see Managing quality gates.

How quality gates are calculated

Within a specific project, the same quality gate definition is always used for all quality gate status calculations. However, the way that the calculations are done differs somewhat between the Main Branch, other Branches, and Pull Requests:

Main branch

For the main branch:

• Both the conditions defined on overall code and conditions defined on new code are applied.
• What counts as new code is determined by the prevailing new code definition setting for the main branch, as described in About new code.

Long-lived branches

For long-lived branches other than the main branch:

• Both the conditions defined on overall code and conditions defined on new code are applied.
• What counts as new code is determined by the prevailing new code definition setting for the branch, as described in About new code.

Short-lived branches

For short-lived branches (not associated with pull requests):

• As with the other cases, the quality gate defined at the project level is used, but only conditions defined on new code are applied.
• And, new code is defined as whatever has changed relative to the target branch, as described in Branch analysis.

Pull requests

• But, only conditions defined on new code are applied.
• And, new code is defined as whatever has changed relative to the target branch, as described in Pull request analysis.

How quality gates are used

The purpose of the quality gate is to tell you whether your code is good enough to be pushed to the next step:

• For the main branch and other long-lived branches, the quality gate answers the question: "Can I release my code today?"
• For pull requests (and short-lived branches), the quality gate answers the question: "Can I merge this pull request?"

By keeping an eye on the quality gate you can quickly judge the status of your code and decide on what to do next.

Using quality gates to control release gates

In addition to providing you with information that you can act on yourself, quality gates can also be hooked up to your build process to automatically control a release gate. A release gate is a mechanism that triggers a build pipeline failure if the quality gate fails.