SonarQube Community Build | DevOps platform integration | GitLab integration | Setting up GitLab integration at project level

Setting up GitLab integration features at the project level

Reporting your quality gate status in GitLab for unbound projects

On SonarQube Community Build projects bound to their GitLab repository, SonarQube Community Build automatically sets up the report of your quality gate status and analysis metrics directly to your GitLab merge requests. For unbound projects, you must set up the quality gate status report manually as explained below (The integration of SonarQube Community Build with GitLab must be properly set up).

To report your quality gate status in GitLab for unbound projects:

In the SonarQube Community Build UI page of your project, select Project Settings > General Settings > DevOps Platform Integration.
Set:
- Configuration name: The name of your GitLab instance's Configuration record set in Setting up the import of GitLab repositories (Ask your system admin.).
- Project ID: Your GitLab project ID (found in GitLab).

Preventing a merge when the quality gate fails

In GitLab, you can block merge requests if it is failing the quality gate. To do this:

In your GitLab repository, go to Your project > Settings > Merge requests.
In the Merge Checks section, select Pipelines must succeed.

More information about GitLab’s External status checks can be found in the GitLab Documentation.

Reporting vulnerabilities in GitLab

This feature is available starting in Developer Edition and requires GitLab Ultimate and GitLab CI/CD.

Report overview

SonarQube Community Build can provide feedback about security vulnerabilities inside the GitLab interface itself. The security issues found by SonarQube Community Build will appear on the Gitlab > Vulnerability report page.

Initially, all issues of type Vulnerability marked Open on SonarQube Community Build are marked as Needs triage on GitLab. When you update the status of an issue in SonarQube Community Build, it is also updated in GitLab. Updating the status of an issue in Gitlab does not update it in SonarQube Community Build.

If issues in GitLab appear duplicated after a modification, users should use the Activity > Still detected filter.

Correspondence of statuses

Because the available statuses on the two systems are not exactly the same, the following logic is used to manage the transitions:

In SonarQube, a transition to	Results in this in GitLab
Open	Needs triage
Confirmed (deprecated)	Confirm
Accepted	Dismiss
Fixed	Resolved

Severity mapping

The following table presents the mapping of the severity levels between SonarQube Community Build and GitLab.

Severity level in Standard Experience	Severity level in MQR Mode	Maps to in GitLab
Blocker	Blocker	Critical
Critical	High	High
Major	Medium	Medium
Minor	Low	Low
Info	Info	Info

Setting up the report

The report is set up through your GitLab CI/CD pipeline. The user starting the analysis in the pipeline must have the Browse permission on your project. This user corresponds to the SonarQube Community Build account used to generate the analysis token in Adding the SonarQube Community Build analysis to your GitLab CI/CD pipeline.

Proceed as follows:

Add a vulnerability report stage to your .gitlab-ci.yml file, as follows:

SonarScanner for Gradle

stages:
    - sonarqube-check
    - vulnerability-report

sonarqube-check:
  stage: sonarqube-check
  image: gradle:8.2.0-jdk17-jammy
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: gradle sonar
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop

vulnerability-report:
  stage: vulnerability-report
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=<projectKey>&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'  # Replace <projectKey> with your project key

  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json
  dependencies:
    - sonarqube-check

SonarScanner for Maven

stages:
    - sonarqube-check
    - vulnerability-report

sonarqube-check:
  stage: sonarqube-check
  image: maven:3.9.3-eclipse-temurin-17
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: 
    - mvn verify sonar:sonar
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop

vulnerability-report:
  stage: vulnerability-report
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=<projectKey>&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json' # Replace <projectKey> with your project key
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json
  dependencies:
    - sonarqube-check

SonarScanner CLI

stages:
    - sonarqube-check
    - vulnerability-report

sonarqube-check:
  stage: sonarqube-check
  image: 
    name: sonarsource/sonar-scanner-cli:latest
    entrypoint: [""]
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: 
    - sonar-scanner
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop

vulnerability-report:
  stage: vulnerability-report
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=<projectKey>&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'  # Replace <projectKey> with your project key
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json
  dependencies:
    - sonarqube-check

SonarScanner for .NET

stages:
    - sonarqube-check
    - vulnerability-report

sonarqube-check:
  stage: sonarqube-check
  image: mcr.microsoft.com/dotnet/core/sdk:latest
  variables:
    SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
    GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
  cache:
    key: "${CI_JOB_NAME}"
    paths:
      - .sonar/cache
  script: 
      - "apt-get update"
      - "apt-get install --yes openjdk-17-jre"
      - "dotnet tool install --global dotnet-sonarscanner"
      - "export PATH=\"$PATH:$HOME/.dotnet/tools\""
      - "dotnet sonarscanner begin /k:\"projectKey" /d:sonar.token=\"$SONAR_TOKEN\" /d:\"sonar.host.url=$SONAR_HOST_URL\" "  # Replace "projectKey" with your project key
      - "dotnet build"
      - "dotnet sonarscanner end /d:sonar.token=\"$SONAR_TOKEN\""
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop

vulnerability-report:
  stage: vulnerability-report
  script:
    - 'curl -u "${SONAR_TOKEN}:" "${SONAR_HOST_URL}/api/issues/gitlab_sast_export?projectKey=<projectKey>&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json'  # Replace <projectKey> with your project key
  allow_failure: true
  only:
    - merge_requests
    - master
    - main
    - develop
  artifacts:
    expire_in: 1 day
    reports:
      sast: gl-sast-sonar-report.json
  dependencies:
    - sonarqube-check

Was this page helpful?

Setting up GitLab integration features at the project level

On this page

.css-4ebt6d{position:relative;--tw-text-opacity:1;color:rgb(0 0 0 / var(--tw-text-opacity));}Reporting your quality gate status in GitLab for unbound projects.css-abpesc{width:2rem;display:none;margin-left:0.5rem;fill:#5F656D;}.css-abpesc:hover{fill:#290042;}

Preventing a merge when the quality gate fails

Reporting vulnerabilities in GitLab

Report overview.css-p7dib0{width:1.75rem;display:none;margin-left:0.5rem;fill:#5F656D;}.css-p7dib0:hover{fill:#290042;}

Setting up the report

Reporting your quality gate status in GitLab for unbound projects

Report overview