Adding analysis to GitLab CI/CD pipeline
You can integrate the SonarQube Server analysis into your GitLab CI/CD pipeline.
Once you have Importing your GitLab repositories in SonarQube, you can add the SonarQube analysis to your GitLab CI/CD pipeline:
Configure the project analysis parameters.
Add the analysis to your GitLab CI/CD pipeline.
Commit and push your code to start the analysis.
You can fail the pipeline when the quality gate fails (see below). If you use a monorepo, see the section If you use a monorepo below. To manage other project-level features, see Setting up GitLab integration at project level.
For more information on configuring your build with GitLab CI/CD, see the GitLab CI/CD configuration reference.
Configuring the project analysis parameters
For general information, see Analysis parameters and the respective SonarScanner section: SonarScanner for Maven, SonarScanner for Gradle, Using the scanner, SonarScanner CLI, and Configuring the scanner.
With GitLab CI/CD, you can securely set sonar.token
and sonar.host.url
properties through CI/CD variables: see Setting the authentication to the SonarQube Server below.
In addition, starting from the Developer Edition, SonarScanners running in GitLab CI/CD can automatically detect branches and merge requests being built so you don’t need to specifically pass them as parameters to the scanner. See Introduction and Introduction for more information.
Configuring your .gitlab-ci-yml file
This section shows you how to configure your GitLab CI/CD .gitlab-ci.yml
file. The allow_failure
parameter in the examples allows a job to fail without impacting the rest of the CI suite.
By default, GitLab will build all branches but not merge requests. To build merge requests, you need to use rules in your .gitlab-ci.yml
. See the example configurations below for more information.
Select the scanner you’re using below to expand an example configuration:
The errors "Missing blame information…" and "Could not find ref…" can be caused by checking out with a partial or shallow clone, or when using Git submodules. You should disable git shallow clone to make sure the scanner has access to all of your history when running analysis with GitLab CI/CD.
For more information, see Git shallow clone.
Failing the pipeline when the quality gate fails
In order for the quality gate to fail on the GitLab side when it fails on the SonarQube Server side, the scanner needs to wait for the SonarQube Server quality gate status. To enable this, set the sonar.qualitygate.wait=true
parameter in the .gitlab-ci.yml
file. See the configuration examples in Configuring your .gitlab-ci-yml file above.
You can set the sonar.qualitygate.timeout
property to an amount of time (in seconds) that the scanner should wait for a report to be processed. The default is 300 seconds.
If you use a monorepo
The Managing monorepo projects is supported starting in the Enterprise Edition provided the GitLab integration with SonarQube Server has been properly Setting up integration at global level.
To add the SonarQube Server analysis to your GitLab’s monorepo CI/CD pipeline:
If not already done, create the SonarQube Server projects related to your monorepo: see Managing monorepo projects.
For each project, set up integration features: see Setting up GitLab integration at project level.
For each project in the monorepo:
Set up the authentication to SonarQube Server (
sonar.token
andsonar.host.url
properties): see Setting up the authentication to the SonarQube Server below.Set the other necessary analysis parameters: see Configuring the project analysis parameters above. The mandatory parameter is:
sonar.projectKey
property.
Add a CI/CD YAML syntax reference (
.gitlab-ci.yml
) in the home directory of the monorepo: Define a job for each monorepo project in.gitlab-ci.yml
.You can fail the pipeline when the quality gate fails: see above.
Last updated
Was this helpful?