SonarQube Cloud | Improving your code | Pull request analysis

Pull request analysis

Pull request analysis is your second line of defense in keeping your code clean. Your first line of defense is using SonarQube for IDE to find issues right in your IDE. Once you have addressed those issues, you can go ahead and create a pull request to merge your changes into the main branch of your project. SonarQube Cloud will automatically analyze the code changes it introduces and report the result, both in the SonarQube Cloud interface and in the pull requests view of your DevOps platform. This step can find issues that are not detectable inside the IDE with SonarQube for IDE, giving you the opportunity to address them before you merge the pull request.

In the SonarQube Cloud Free plan, pull request analysis is available only when the pull request is merged into the main branch. Please see the Comparison table on the Subscription plans for plan details.

The term pull request is used by most repository providers. GitLab, however, uses the term “merge request”. Both terms refer to the same functionality and are handled equivalently in Sonar products. In our documentation, any use of the term pull request applies equally to GitLab merge requests.

Understanding your pull request analysis

From the project, if you click on Pull Requests, the pull requests for which an analysis has been done will be displayed:

For each pull request in the list, the name of the pull request, the commit at which the latest analysis was performed, and the resulting status of the quality gate on that pull request are displayed. Click on the name of the pull request to drill down further:

Pull request decoration

In addition to appearing in the SonarQube Cloud interface, the quality gate status and a summary of the results also appear in your DevOps platform interface (that is, in the pull request view of GitHub, Bitbucket Cloud, Azure DevOps or GitLab). This is referred to as pull request decoration. But, it is not just decorative! It also integrates with your DevOps platform to block the merge of the pull request if the quality gate fails. In this way, you can benefit from SonarQube Cloud analysis without even leaving the environment of your DevOps platform.

A pull request decoration will look like this (it is similar on the supported platforms):

Summary of the results and the quality gate status on a PR.

Quality gate and metrics

Pull request analysis differs from main branch (and other long-lived branch) analysis in two important ways:

Pull request analysis only reports issues that were introduced by the pull request itself. When SonarQube Cloud analyzes a pull request P for the merge of branch B into base branch T it scans the HEAD commit of B and compares the result with the most recent scan of T. Only issues that appear in B but not in T are reported in the analysis results. In cases where T includes new issues added since the most recent scan (in other words the scan is outdated) those additional issues will appear as part of the pull request analysis, even though they were not introduced by the pull request.
The quality gate for the pull request is computed based on this analysis. The quality gate used is the one set at the project level, however, only the conditions on new code within the quality gate are applied.

As outlined above, the scanner starts by analyzing the HEAD commit, the most recent commit in your current branch. If the head commit is not defined, it scans the remote branch and, if that is not available, the upstream branch.

Above you can see that on the Summary tab, the quality gate and the five quality metrics are displayed. In addition, the other tabs, Issues, Measures, and Code let you see more details about the analysis.

Enabling pull request analysis

Pull request analysis is available on all supported repository providers. Of course, to see an analysis result, an analysis must be performed on the pull request. If you are using automatic analysis (which is only available on GitHub) then this happens without any further configuration on pull request creation and on every push to the pull request branch. If you are using build analysis then you must make sure that your build script is configured to build on pull request creation and push.

Prerequisites for CI-based analysis

Before analyzing your pull requests, make sure that:

The pull request source branch is checked out in CI/CD host's local repository.
The branch being targeted by the pull request is fetched and present in the local repository (This is usually done through the cloning of the remote repository by the CI pipeline).
The local repository contains valid repository metadata (e.g. the .git folders have not been removed).
See Verifying the code checkout step.
The code in the local repository matches the code in the remote repository (e.g once a pull request is issued, no code is added to the local branch on the CI side before analysis).

Existing pull requests on first automatic analysis

When a project is first imported into SonarQube Cloud and analyzed by automatic analysis the first analysis behaves differently from subsequent analyses. On the first analysis not only will the main branch be analyzed, but, also the most recently active pull requests, up to a maximum of five. The main branch and pull request results will appear on the project overview, as usual. Subsequent analyses will occur normally, on pushes to the main branch and on pushes to pull request branches.