How to Automate Code Quality with GitLab CI/CD and SonarQube

Overall Architecture

When a push or merge request is made, GitLab CI/CD runs a pipeline that executes SonarQube analysis. The pipeline outcome determines whether the merge can proceed.

Four services are involved:

GitLab CI – entry point for CI jobs.

GitLab Runner – executes the analysis.

SonarQube – provides quality rules, analysis, and dashboards.

SonarNotify (or SonarQube DingTalk plugin) – formats SonarQube reports and sends notifications to DingTalk, mentioning project owners.

Step 1 – Configure GitLab CI Environment

1.1 Enable CI/CD

In a new project CI/CD is enabled by default. If not, go to Settings → General → Visibility, project features, permissions → CI/CD and toggle the switch.

1.2 Register a Specific Runner

Run the following command on a server with GitLab Runner installed:

sudo gitlab-runner register --url $YOUR_GIT_REPO \
    --registration-token $REGISTRATION_TOKEN

When prompted, set the runner tags to merchant-ci and choose the shell executor.

Step 2 – Set Up SonarQube

2.1 Create a SonarQube Project

If the project does not exist, create it in SonarQube and note the generated token.

2.2 Run the First Analysis

Execute the scanner command provided by the SonarQube UI. For Java back‑end projects use Maven or Gradle wrappers.

2.3 Define Quality Gates

Typical thresholds (adjust to team standards):

Coverage < 50%

Bugs > 0

Blocker violations > 0

Critical violations > 0

2.4 Configure Webhook Notification

Set a global (or project‑specific) webhook that posts analysis results to the SonarNotify service, which forwards them to DingTalk.

Step 3 – Project Configuration

3.1 Add .gitlab-ci.yml

Place the following file at the repository root:

variables:
  APP_NAME: "xxx-project"
include:
  - project: 'zcy/ci'
    file: '/.gitlab-ci-template.yml'

APP_NAME must match the SonarQube project name. The included template centralises CI definitions across projects.

3.2 Add SonarQube Maven Plugin

Insert the SonarQube Maven plugin into pom.xml (example omitted for brevity).

3.3 Exclude Unwanted Code from Analysis

Use SonarQube properties in pom.xml to skip modules, packages, or test files:

<properties>
  <sonar.skip>true</sonar.skip>
  <sonar.exclusions>**/*Model.java</sonar.exclusions>
  <sonar.test.exclusions>src/test/**/*</sonar.test.exclusions>
  <sonar.coverage.exclusions>**/domain/**/*, **/pojos/*</sonar.coverage.exclusions>
</properties>

Result Preview

1. DingTalk Notification

2. SonarQube Analysis Details

View the project in the SonarQube UI to see metrics, issues, and coverage.

3. GitLab MR Blocking

If the quality gate fails, the merge request cannot be merged.

Conclusion

Embedding SonarQube analysis into GitLab CI/CD creates an automated quality gate that enforces coding standards on every push or merge request, improving overall development quality.

References

GitLab CI/CD with Kubernetes – https://docs.gitlab.cn/jh/user/clusters/agent/ci_cd_workflow.html

SonarQube webhook documentation – https://docs.sonarqube.org/latest/project-administration/webhooks/

GitLab CI/CD official documentation – https://docs.gitlab.cn/jh/ci/