Analyze Your Repository With GitLab CI
You can integrate SonarCloud analysis into your GitLab CI pipeline.
Add environment variables
Define the SONAR_TOKEN environment variable
On SonarCloud go to My account > Security > Generate Tokens to generate a fresh token that GitLab CI can use.
In GitLab, go to Settings and then CI/CD Variables to add the following variable and make sure it is available for your project:
- In the Key field, enter
SONAR_TOKEN
- In the Value field, enter the token you generated on SonarCloud
- Tick the Masked checkbox (this will prevent GitLab from showing the token in your build logs)
Define the SONAR_HOST_URL environment variable
In GitLab, go to Settings and then CI/CD Variables to add the following variable and make sure it is available for your project. You can define it for each of your GitLab projects or only once on the parent GitLab group.
- In the Key field, enter
SONAR_HOST_URL
- In the Value field, enter
https://sonarcloud.io
- No need to tick the Masked checkbox this time
Create or update the gitlab-ci.yml file
Choose the build technology relevant to your project.
Maven
Update your pom.xml
file with the following properties:
Create or update your .gitlab-ci.yml
file with the following content:
Gradle
Create or update your .gitlab-ci.yml
file with the following content:
Other (for JS, TS, Go, Python, PHP, ...)
Create or update your .gitlab-ci.yml
file with the following content.
Create a sonar-project.properties
file in the root directory of the project:
Failing the pipeline job when the SonarCloud Quality Gate fails
In order for the pipeline to stop on GitLab CI side when the Quality Gate fails on SonarCloud side, the SonarScanner needs to wait for the report and Quality Gate status to be processed by SonarCloud. To enable this feature, you can set the sonar.qualitygate.wait=true
parameter in your sonar-project.properties
or .gitlab-ci.yml
file.
You can also set the sonar.qualitygate.timeout
property to a maximum amount of time (in seconds) that the SonarScanner should wait for a report to be processed. The default is 300 seconds. Reaching this timeout will count as a failure and stop the GitLab CI pipeline.
It is also possible to allow a job to fail without impacting the rest of the CI suite with the allow_failure: true
parameter of GitLab CI. The failing job won't stop the pipeline but will be displayed as in a warning state.
Merge request decoration
The decoration of your merge requests is automatically configured as soon as you import a project and set up your GitLab CI.
The same access token used for connecting your GitLab group to SonarCloud is used to post comments on the merge request. It makes it all the more important to use a technical GitLab account to generate the token.
Analyzing Monorepo Projects: Build Configuration
The example below shows how you could set up a yml file for multiple projects in a monorepo. If you want to analyze a monorepo that contains more than one project ensure that you specify the paths to each sub-project for analysis in your build file.
To ensure that your monorepo works as expected, you need to build each project in the monorepo separately with a valid token. Each project of the monorepo can be configured with its own properties file. Gitlab only accepts one SONAR_TOKEN (in the CI/CD Variables configuration) per Gitlab project so you do not need to pass tokens for each project within your monorepo.
See the section on environment variables at the top of this page for more information on setting up your token.
Below is a sample .gitlab-ci.yml
file that assumes your build requires the Sonar Scanner CLI, see the examples above if your setup uses an alternative configuration.
Was this page helpful?