> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/10.7/devops-platform-integration/gitlab-integration/setting-up-at-project-level.md). # Setting up GitLab integration at project level This section explains how to set up various GitLab integration features for a given project in SonarQube Server 10.7. {% hint style="info" %} **For AI agents:** You're in the SonarQube Server 10.7 documentation. For a list of all 10.7 pages, see the [SonarQube Server 10.7 page index](https://3272878703-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FI10pmJWeVVXYITlQJllp%2Fuploads%2FnEeIaIlHm7ezec5g9iHc%2Fsonarqube-server-10.7-llms.txt?alt=media). For the whole site, see the [page index](https://docs.sonarsource.com/llms.txt) or the [full text](https://docs.sonarsource.com/llms-full.txt). For another version, replace 10.7 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL. {% endhint %} This section explains how to set up various GitLab integration features for a given project. ## Reporting your quality gate status in GitLab for unbound projects On SonarQube Server projects [Importing your GitLab repositories](/sonarqube-server/10.7/devops-platform-integration/gitlab-integration/importing-repos.md), SonarQube Server 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 Server with GitLab must be properly [Setting up integration at global level](/sonarqube-server/10.7/devops-platform-integration/gitlab-integration/global-setup.md)). To report your quality gate status in GitLab for unbound projects: 1. In the SonarQube Server UI page of your project, select **Project Settings > General Settings > DevOps Platform Integration**. 2. Set: * **Configuration name**: The name of your GitLab instance’s Configuration record set in [Setting up integration at global level](/sonarqube-server/10.7/devops-platform-integration/gitlab-integration/global-setup.md) (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: 1. In your GitLab repository, go to *Your project* **> Settings > Merge requests.** 2. In the **Merge Checks** section, select **Pipelines must succeed**. More information about GitLab’s External status checks can be found in the [GitLab Documentation](https://docs.gitlab.com/ee/user/project/merge_requests/status_checks.html#block-merges-of-merge-requests-unless-all-status-checks-have-passed). ## Reporting vulnerabilities in GitLab This feature is available starting in [Developer Edition](https://www.sonarsource.com/plans-and-pricing/developer/) and requires GitLab Ultimate and GitLab CI/CD. ### Report overview SonarQube Server can provide feedback about security vulnerabilities inside the GitLab interface itself. The security issues found by SonarQube Server will appear on the **Gitlab > Vulnerability** report page. Initially, all issues of type Vulnerability marked **Open** on SonarQube Server are marked as **Needs triage** on GitLab. When you update the status of an issue in SonarQube Server, it is also updated in GitLab. Updating the status of an issue in Gitlab does not update it in SonarQube Server. {% hint style="info" %} If issues in GitLab appear duplicated after a modification, users should use the **Activity > Still detected** filter. {% endhint %}
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 Server, 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 Server and GitLab. | Severity level in SonarQube Server | Is mapped to, in GitLab | | ---------------------------------- | ----------------------- | | High | High | | Medium | Medium | | Low | Low |
### 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 (see [Security features](/sonarqube-server/10.7/instance-administration/system-functions/security.md)). This user corresponds to the SonarQube Server account used to generate the analysis token in [Adding analysis to GitLab CI/CD pipeline](/sonarqube-server/10.7/devops-platform-integration/gitlab-integration/adding-analysis-to-gitlab-ci-cd.md). Proceed as follows: * Add a vulnerability report stage to your `.gitlab-ci.yml` file, as follows:
SonarScanner for Gradle ```css-79elbk 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=&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json' # Replace 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 ```css-79elbk 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=&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json' # Replace 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 ```css-79elbk 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=&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json' # Replace 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 ```css-79elbk stages: - sonarqube-check - vulnerability-report sonarqube-check: stage: sonarqube-check image: mcr.microsoft.com/dotnet/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=&branch=${CI_COMMIT_BRANCH}&pullRequest=${CI_MERGE_REQUEST_IID}" -o gl-sast-sonar-report.json' # Replace 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 ```
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.sonarsource.com/sonarqube-server/10.7/devops-platform-integration/gitlab-integration/setting-up-at-project-level.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.