# Pull request analysis

*Pull Request analysis is available starting in* [*Developer Edition*](https://www.sonarsource.com/plans-and-pricing/developer/)*.*

You can see your pull requests in SonarQube from the branches and pull requests dropdown menu of your project.

Pull request analysis shows your pull request’s quality gate and analysis in the SonarQube interface. This analysis shows new issues introduced by the pull request before merging with the target branch:

![View of a sample PR analysis with metrics](https://3691828591-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Feu7dHWcqP9Cr3eUAzwWg%2Fuploads%2Fgit-blob-0d1dc344833e27aaf713c67c9a3db9cd21289c20%2F9cf109c25968e786a3d8ca8d8377c853a88d0988.png?alt=media)

View of a sample PR analysis with metrics

The new code should be your focus moving forward when using the [clean-as-you-code](https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/clean-as-you-code "mention") strategy. More about this can be found in the SonarQube [concepts](https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/concepts "mention") pages.

## Prerequisites <a href="#prerequisites" id="prerequisites"></a>

Before analyzing your pull requests, make sure that:

* The pull request source branch is checked out in the local repository.
* The branch being targeted by the pull request is fetched and present in the local repository.
* The analysis is being run on a local repository with valid repository metadata (e.g. the `.git` folders have not been removed). Avoid any attempt at previewing the merge or actions involving your main branch.
* The code in the local repository matches the code in the remote repository (e.g once a PR is issued, no code is added to the local branch on the CI side before analysis).

## Report pull request status to your DevOps Platform <a href="#pull-request-status" id="pull-request-status"></a>

You can also report the pull request analysis and quality gate status directly in your DevOps platform’s interface. To set up pull request decoration, see the DevOps platform integration page that corresponds with your DevOps platform:

* [introduction](https://docs.sonarsource.com/sonarqube-server/10.5/devops-platform-integration/github-integration/introduction "mention")
* [bitbucket-server-integration](https://docs.sonarsource.com/sonarqube-server/10.5/devops-platform-integration/bitbucket-integration/bitbucket-server-integration "mention")
* [bitbucket-cloud-integration](https://docs.sonarsource.com/sonarqube-server/10.5/devops-platform-integration/bitbucket-integration/bitbucket-cloud-integration "mention")
* [gitlab-integration](https://docs.sonarsource.com/sonarqube-server/10.5/devops-platform-integration/gitlab-integration "mention")
* [azure-devops-integration](https://docs.sonarsource.com/sonarqube-server/10.5/devops-platform-integration/azure-devops-integration "mention")

{% hint style="info" %}
To decorate pull requests, a SonarQube analysis needs to be run on your code. You can find the additional parameters required for pull request analysis below in the **Analysis Parameters** section.
{% endhint %}

## Pull request quality gate <a href="#quality-gate" id="quality-gate"></a>

A [quality-gates](https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/quality-gates "mention") lets you ensure you are meeting your organization’s quality policy and that you can merge your pull request. The pull request uses your project quality gate as follows:

* **Focuses on new code**: The pull request quality gate only uses your project’s quality gate conditions that apply to new code metrics using the [clean-as-you-code](https://docs.sonarsource.com/sonarqube-server/10.5/user-guide/clean-as-you-code "mention") strategy.
* **Assigns a status**: Each pull request shows a quality gate status reflecting whether it passed or failed.

Pull request analyses on SonarQube are deleted automatically after 30 days with no analysis. This can be updated in **Administration** > **Configuration** > **General Settings** > **Housekeeping** > **Number of days before purging inactive branches**.

## Analysis parameters <a href="#analysis-parameters" id="analysis-parameters"></a>

The following parameters enable Pull Request analysis.

{% hint style="info" %}
Scanners can automatically detect Pull Request parameters when running on the following CI services:

* Azure Pipelines
* Bitbucket Pipelines
* Cirrus CI
* Codemagic
* GitHub Actions
* GitLab CI/CD
* Jenkins (with the Branch Source plugin configured)

Manually setting Pull Request parameters overrides automatic detection.
{% endhint %}

|                            |                                                                                                                                                                      |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Parameter Name**         | **Description**                                                                                                                                                      |
| `sonar.pullrequest.key`    | <p>Unique identifier of your Pull Request. Must correspond to the key of the Pull Request in your DevOps Platform.<br>e.g.: <code>sonar.pullrequest.key=5</code></p> |
| `sonar.pullrequest.branch` | <p>The name of the branch that contains the changes to be merged.<br>e.g.: <code>sonar.pullrequest.branch=feature/my-new-feature</code></p>                          |
| `sonar.pullrequest.base`   | <p>The branch into which the Pull Request will be merged.<br>Default: main branch<br>e.g.: <code>sonar.pullrequest.base=main</code></p>                              |
