How to Publish a Coverage Report in a Jenkins Pipeline

By Kaveh Alemi·Latchkey

The Jenkins Coverage plugin parses a coverage report and can fail the build on a quality-gate threshold.

Generate a Cobertura/JaCoCo report in the test stage, then call recordCoverage (Coverage plugin) in a post block with qualityGates to enforce a minimum.

Record coverage with a quality gate

Tests emit a Cobertura report; recordCoverage publishes it and fails below 80% line coverage.

pipeline {
  agent any
  stages {
    stage('Test') {
      steps { sh 'npm ci && npm test -- --coverage' }
    }
  }
  post {
    always {
      recordCoverage(
        tools: [[parser: 'COBERTURA', pattern: 'coverage/cobertura-coverage.xml']],
        qualityGates: [[threshold: 80.0, metric: 'LINE', baseline: 'PROJECT']]
      )
    }
  }
}

Gotchas

• Requires the Coverage plugin; the older Cobertura plugin uses a different cobertura step.
• Run recordCoverage in post { always {} } so the report publishes even when tests fail.
• A failed quality gate marks the build UNSTABLE/FAILED depending on config - set it intentionally.

Verify it actually works

Validate the pipeline definition against the running controller before committing. Jenkins parses declarative pipelines strictly, and a syntax error surfaces as a failed build rather than a clear parse message.

# validate a Jenkinsfile against the live controller
curl -X POST -F "jenkinsfile=<Jenkinsfile" \
  https://your-jenkins/pipeline-model-converter/validate

# replay a build with modified script to test a change without committing
# Build page -> Replay -> edit -> Run

Agent and workspace assumptions that break in CI

• An agent label that matches no online agent leaves the build queued indefinitely rather than failing.
• Workspaces are reused between builds by default, so stale files from a previous run can mask or cause failures. Use cleanWs() or a fresh workspace when correctness matters.
• Tools resolved from the controller PATH are not necessarily on the agent PATH. Declare them in a tools block or install them in the pipeline.
• Credentials bound with withCredentials are masked in logs but still visible to any process you launch; avoid passing them as command-line arguments.

Frequently asked questions

Related guides

References

• GitHub Actions documentation