Bitbucket Server integration
SonarQube's integration with Bitbucket Server allows you to maintain code quality and security in your Bitbucket Server repositories.
With this integration, you'll be able to:
- Import your BitBucket Server repositories: Import your Bitbucket Server repositories into SonarQube to easily set up SonarQube projects.
- Add pull request decoration: (starting in Developer Edition) See your Quality Gate and code metric results right in Bitbucket Server so you know if it's safe to merge your changes.
Prerequisites
Integration with Bitbucket Server requires at least Bitbucket Server version 5.15.
Branch Analysis
Community Edition doesn't support the analysis of multiple branches, so you can only analyze your main branch. Starting in Developer Edition, you can analyze multiple branches and pull requests.
Importing your Bitbucket Server repositories into SonarQube
Setting up the import of BitBucket Server repositories into SonarQube allows you to easily create SonarQube projects from your Bitbucket Server repositories. If you're using Developer Edition or above, this is also the first step in adding pull request decoration.
To import your Bitbucket repositories into SonarQube, you can only have one global configuration of Bitbucket, including Bitbucket Server and Bitbucket Cloud. See the Configuring multiple DevOps platform instances section below for more information.
To set up the import of BitBucket Server repositories:
- Set your global DevOps Platform integration settings
- Add a personal access token for importing repositories
Setting your global ALM integration settings
To set your global ALM Integration settings, navigate to Administration > ALM Integrations, select the Bitbucket tab, and select Bitbucket Server as the variant you want to configure. From here, specify the following settings:
- Configuration Name (Enterprise and Data Center Edition only): The name used to identify your Bitbucket Server configuration at the project level. Use something succinct and easily recognizable.
- Bitbucket Server URL: your instances URL. For example,
https://bitbucket-server.your-company.com
. - Personal Access Token – A Bitbucket Server user account is used to decorate pull requests. We recommend using a dedicated Bitbucket Server account with Administrator permission. You need a Personal Access Token from this account with Write permission for the repositories that will be analyzed. This personal access token is used for pull request decoration, and you'll be asked for another personal access token for importing projects in the following section.
Adding a personal access token for importing repositories
After setting your global settings, you can add a project from Bitbucket Server by clicking the Add project button in the upper-right corner of the Projects homepage and selecting Bitbucket.
Then, you'll be asked to provide a personal access token from your user account with Read
permissions for both projects and repositories. This token will be stored in SonarQube and can be revoked at any time in Bitbucket Server.
After saving your personal access token, you'll see a list of your Bitbucket Server projects that you can set up and add to SonarQube. Setting up your projects this way also sets your project settings for pull request decoration.
Adding pull request decoration to the Bitbucket server
Pull request decoration shows your quality gate and analysis metrics directly in Bitbucket Server.
After you've set up SonarQube to import your Bitbucket Server repositories as shown in the previous section, the simplest way to add pull request decoration is by adding a project from Bitbucket Server. Select the Add project button in the upper-right corner of the Projects homepage and choose Bitbucket.
Then, follow the steps in SonarQube to analyze your project. The project settings for pull request decoration are set automatically.
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 on the Pull request analysis page.
Adding pull request decoration to a manually created or existing project
To add pull request decoration to a manually created or existing project, make sure your global ALM Integration settings are configured as shown in the Importing your Bitbucket Server repositories into SonarQube section above, and set the following project settings at Project Settings > General Settings > Pull Request Decoration:
- Configuration name: The configuration name that corresponds to your DevOps Platform instance.
- Project Key: the project key is part of your BitBucket Server repository URL
(.../projects/
<key>
/repos/<slug>/browse).
- Repository SLUG: The repository slug is part of your BitBucket Server repository URL
(.../projects/<key>/repos/
<slug>
/browse).
Advanced pull request configuration
Adding pull request decoration to projects that are part of a mono repository
Pull request decoration for a mono repository setup is supported starting in Enterprise Edition.
In a mono repository setup, multiple SonarQube projects, each corresponding to a separate project within the mono repository, are all bound to the same Bitbucket Server repository. You'll need to set up pull request decoration for each SonarQube project that is part of a mono repository.
To add pull request decoration to a project that's part of a mono repository, set your project up manually as shown in the Adding pull request decoration to a manually created or existing project section above. You also need to set the Enable mono repository support setting to true at Project Settings > General Settings > Pull Request Decoration.
After setting your project settings, you need to ensure the correct project is being analyzed by adjusting the analysis scope and pass your project names to the scanner. See the following sections for more information.
Ensuring the correct project is analyzed
You need to adjust the analysis scope to make sure SonarQube doesn't analyze code from other projects in your mono repository. To do this set up a Source File Inclusion for your project at Project Settings > Analysis Scope with a pattern that will only include files from the appropriate folder. For example, adding ./MyFolderName/**/*
to your inclusions would only include analysis of code in the MyFolderName
folder. See Narrowing the Focus for more information on setting your analysis scope.
Passing project names to the scanner
Because of the nature of a mono repository, SonarQube scanners might read all project names of your mono repository as identical. To avoid having multiple projects with the same name, you need to pass the sonar.projectName
parameter to the scanner. For example, if you're using the Maven scanner, you would pass mvn sonar:sonar -Dsonar.projectName=YourProjectName
.
Configuring multiple ALM instances
You can decorate pull requests from multiple ALM instances by creating a configuration for each ALM instance and then assigning that instance configuration to the appropriate projects.
- As part of Developer Edition, you can create one configuration for each ALM.
- Starting in Enterprise Edition, you can create multiple configurations for each ALM. If you have multiple configurations of the same ALM connected to SonarQube, you have to create projects manually.
Linking issues
During pull request decoration, individual issues will be linked to their SonarQube counterparts automatically. For this to work correctly, you need to set the instance's Server base URL (Administration > Configuration > General Settings > General > General) correctly. Otherwise, the links will default to localhost
.
Preventing pull request merges when the quality gate fails
After setting up pull request analysis, you can block pull requests from being merged if it is failing the quality gate. To do this:
- In Bitbucket Server, navigate to Repository settings > Code Insights.
- Add a Required report called
com.sonarsource.sonarqube
If your SonarQube project is configured as part of a mono repository in Enterprise Edition or above, you need to use a Required report that uses a SonarQube project key (com.sonarsource.sonarqube_{sq-project-key}
instead of com.sonarsource.sonarqube
).
This report will be in the format of com.sonarsource.sonarqube_{hash}
(instead of com.sonarsource.sonarqube
). This hash is a randomly computed value that can be discovered on Bitbucket after the first PR analysis.
- Select Must pass as the Required status.
- Select Must not have any annotations as the Annotation requirements.
Was this page helpful?