Implementing Incremental Code Coverage in MR/Push Pipelines with GitLab, Jenkins, and SonarQube

When quality is built‑in, testing is shifted left, and continuous integration/DevOps is required, incremental coverage becomes a mandatory metric. The article outlines a full workflow where each code submission triggers a pipeline that enforces the principle "who writes the code, who owns the coverage".

The process assumes you already have a GitLab + Jenkins + Jacoco + SonarQube pipeline that can be triggered by merge‑request or push events. The steps are:

GitLab sends a webhook (push or MR) to a Jenkins job URL, with token configuration.

The webhook starts a Jenkins job, which can be a freestyle or pipeline job, possibly a custom DevOps platform.

The pipeline runs unit/integration tests and generates a Jacoco coverage report; at this stage many teams parse the diff and the report to compute incremental coverage.

The pipeline invokes Sonar Scanner, which sends results to SonarQube for analysis.

If SonarQube reports that coverage or other quality‑gate metrics do not meet the defined thresholds, the Jenkins job fails.

GitLab receives the result: it can reject the push or annotate the merge request, preventing the code from being merged.

The article then details how to use SonarQube webhooks to push quality‑gate results back to Jenkins. Example webhook payload:

{
    "serverUrl": "http://localhost:9000",
    "taskId": "AVh21JS2JepAEhwQ-b3u",
    "status": "SUCCESS",
    "analysedAt": "2016-11-18T10:46:28+0100",
    "revision": "c739069ec7105e01303e8b3065a81141aad9f129",
    "project": {
        "key": "myproject",
        "name": "My Project",
        "url": "https://mycompany.com/sonarqube/dashboard?id=myproject"
    },
    "qualityGate": {
        "conditions": [{
            "errorThreshold": "80",
            "metric": "new_coverage",
            "onLeakPeriod": true,
            "operator": "LESS_THAN",
            "status": "NO_VALUE"
        }],
        "name": "SonarQube way",
        "status": "OK"
    }
}

In the Jenkins pipeline, the SonarQube analysis stage can wait for the quality gate:

stage ("SonarQube analysis") {
    steps {
        withSonarQubeEnv('SonarQube') {
            sh "mvn clean test sonar:sonar"
        }
        def qualitygate = waitForQualityGate()
        if (qualitygate.status != "OK") {
            error "Pipeline aborted due to quality gate coverage failure: ${qualitygate.status}"
        }
    }
}

After SonarQube notifies Jenkins, Jenkins can update GitLab commit status using the GitLab plugin:

stages {
    stage('gitlab') {
        steps {
            echo 'Notify GitLab'
            updateGitlabCommitStatus name: 'build', state: 'pending'
            updateGitlabCommitStatus name: 'build', state: 'success'
        }
    }
}

Two main approaches to calculate incremental coverage are presented: (1) use a custom or open‑source tool (e.g., diff_cover) to parse the Jacoco report and the Git diff; (2) let SonarQube compute the coverage on a short‑lived branch (e.g., mr‑xxxx ) against a long‑term baseline branch (e.g., develop ), which requires the SonarQube branch plugin or a commercial edition.

Finally, the article summarizes that by combining SonarQube webhooks, the branch plugin, and GitLab status updates, a typical three‑tool integration can be extended to provide true incremental coverage metrics and enforce quality gates automatically.