title: Pull Request Analysis
Pull Request analysis is available as part of Developer Edition and above.
Pull Request analysis allows you to:
PRs are visible in {instance} from the “branches and pull requests” dropdown menu of your project.
When PR decoration is enabled, {instance} publishes the status of the analysis (Quality Gate) on the PR.
When “Confirm”, “Resolved as False Positive” or “Won’t Fix” actions are performed on issues in {instance} UI, the status of the PR is updated accordingly. This means, if you want to get a green status on the PR, you can either fix the issues for real or “Confirm”, “Resolved as False Positive” or “Won’t Fix” any remaining issues available on the PR.
PR analyses on {instance} are deleted automatically after 30 days with no analysis. This can be updated in Configuration > General > Number of days before purging inactive short living branches.
If your repositories are hosted on GitHub, Bitbucket Cloud or Azure DevOps, check out first the dedicated Integrations for: BitBucketCloud, GitHub, and Azure DevOps. Chances are that you do not need to read this page further since those integrations handle the configuration and analysis parameters for you.
These parameters enable PR analysis:
Parameter Name | Description |
---|---|
sonar.pullrequest.branch |
The name of your PR Ex: sonar.pullrequest.branch=feature/my-new-feature |
sonar.pullrequest.key |
Unique identifier of your PR. Must correspond to the key of the PR in GitHub or TFS. E.G.: sonar.pullrequest.key=5 |
sonar.pullrequest.base |
The long-lived branch into which the PR will be merged. Default: master E.G.: sonar.pullrequest.base=master |
To activate PR decoration, you need to:
The first thing to configure is the authentication token that will be used by {instance} to decorate the PRs. This can be configured in Administration > General Settings > Pull Requests. The field to configure depends on the provider. For GitHub Enterprise or GitHub.com, you need to configure the Authentication token field. For Azure DevOps, it’s the Personal access token. If you are using Azure DevOps, the first thing to configure is the authentication token that will be used by {instance} to decorate the PRs. This can be configured in Administration > General Settings > Pull Requests > VSTS > Personal access token.
Parameter Name | Description |
---|---|
sonar.pullrequest.provider |
github or vsts or bitbucketcloud . This is the name of the system managing your PR. In Azure DevOps, when the {instance} Extension for Azure DevOps is used, sonar.pullrequest.provider is automatically populated with “vsts”. Same on GitHub if you are using the Travis CI Add-on, and on Bitbucket Cloud if you are building with Bitbucket Pipelines. |
Parameter Name | Description |
---|---|
sonar.pullrequest.github.repository |
SLUG of the GitHub Repo |
| sonar.pullrequest.github.endpoint
| The API url for your GitHub instance.
Ex.: https://api.github.com/
or https://github.company.com/api/v3/
|
Note: if you were relying on the GitHub Plugin, its properties are no longer required and they must be removed from your configuration: sonar.analysis.mode
, sonar.github.repository
, sonar.github.pullRequest
, sonar.github.oauth
.
Parameter Name | Description | Example value |
---|---|---|
sonar.pullrequest.bitbucketcloud.repository |
UUID of the Bitbucket Cloud Repo | {d2615dd4-550d-43e5-80c4-665f951e5d6e} |
sonar.pullrequest.bitbucketcloud.owner |
UUID of the Bitbucket Cloud Owner | {4f9fd128-1b08-49ec-bf2c-f094163cff4d} |
During pull request decoration, individual issues will be linked to their SonarQube counterparts automatically. However, for this to work correctly, the instance’s Server base URL (Administration > General) must be set correctly. Otherwise the links will default to localhost
.