If you upload a coverage report alongside a security scan, TigerGate records the scan’s overall line coverage, shows it (with a per-repo trend) on the run’s Coverage tab, and can fail the quality gate when coverage is below a configured floor.
The combination is useful because:
- A
CRITICAL finding in a repo with falling coverage is a worse signal than one in a well-tested codebase — pairing the two on the same PR comment surfaces both at once.
- Coverage regresses silently. Surfacing it on every run and PR — and failing the gate below a floor — keeps it in front of you instead of drifting unnoticed.
The --coverage-report upload carries aggregate line coverage (overall percentage plus covered / total line counts), not per-file or per-line data. Coverage is tracked and gated at the repo/scan level — individual findings are not tagged “tested/untested” from it.
| Format | Tool that emits it | Filename convention |
|---|
| lcov | Most JS/TS test runners (jest --coverage, nyc, istanbul) | lcov.info |
| Cobertura | Python coverage.py, .NET coverlet (-f cobertura), generic | cobertura.xml |
| JaCoCo | JVM (mvn test, gradle jacocoTestReport) | jacoco.xml |
| Go cover profile | Go (go test -coverprofile) | coverage.out |
The format is auto-detected by file content; the filename is just convention. OpenCover XML is not parsed — for .NET, emit Cobertura instead (coverlet -f cobertura).
Upload from CI
Add the coverage report path to your scan invocation:
GitHub Actions
GitLab CI
Jenkins
CLI (any CI)
- uses: actions/checkout@v4
- name: Run tests with coverage
run: npm test -- --coverage # produces coverage/lcov.info etc.
- name: TigerGate scan + upload coverage
run: |
docker run --rm \
-e TIGERGATE_API_KEY \
-e GITHUB_REF -e GITHUB_BASE_REF -e GITHUB_HEAD_REF \
-e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_EVENT_NAME \
-v "$PWD":/workspace -w /workspace \
tigergate/tigergate-cli:latest \
scan --type all --upload \
--coverage-report coverage/lcov.info
env:
TIGERGATE_API_KEY: ${{ secrets.TIGERGATE_API_KEY }}
Run your tests before the scan step so the report exists by the time TigerGate looks for it.test:
stage: test
script:
- npm test -- --coverage
artifacts:
paths:
- coverage/
tigergate-scan:
stage: test
needs: [test]
image: tigergate/tigergate-cli:latest
script:
- tigergate scan --type all --upload --coverage-report coverage/lcov.info
stage('Test') {
steps {
sh 'npm test -- --coverage'
}
}
stage('Security Scan') {
steps {
sh '''
tigergate scan --type all --upload \
--coverage-report coverage/lcov.info
'''
}
}
tigergate scan --type all --upload \
--coverage-report coverage/lcov.info
Pass --coverage-report <path> (lcov, cobertura, jacoco, or go-cover). Add --coverage-html ./coverage/html to also upload a browsable HTML report as a dashboard artifact.
What you see
On the run’s Coverage tab
Open a scan run (CI/CD → run detail) and select the Coverage tab. It shows the scan’s line-coverage percentage, lines covered / total, file count, and new-code coverage for the PR when it can be computed — the aggregate report often can’t provide it, in which case it is left blank rather than estimated. A Coverage Trend chart plots overall (and new-code) coverage across the repository and branch’s scan history. When you also pass --coverage-html, View / Download buttons for the uploaded HTML report appear here.
Because the upload is aggregate, these are repo/scan-level numbers — not broken down per finding or per file.
Across repositories
Code Security → Repositories surfaces an Avg Coverage tile and a per-repo coverage column.
When coverage is uploaded, the PR summary comment shows the scan’s finding counts plus overall and new-code coverage percentages, alongside the quality-gate result (which fails when coverage is below a configured floor).
Configuring the gate to fail on low coverage
The quality gate treats coverage as absolute floors — there is no regression-delta gate. Both are off (unset) by default:
| Threshold | Fires when |
|---|
| Minimum coverage | The scan’s overall line coverage is below the floor (e.g. 60%) |
| Minimum new-code coverage | Coverage of the lines this PR changed is below the floor |
Minimum new-code coverage is set in the CI/CD → Quality Gates form, under Evaluate on new code only; it is enforced only when the CLI can compute new-code coverage (otherwise the check is skipped, not failed). See Quality gates for the surrounding gate knobs.
Multi-language repos
The CLI takes one coverage report per scan (--coverage-report). For a
multi-language repo, merge the per-language reports into a single lcov/cobertura
file in your test stage before the scan, then point --coverage-report at the
merged file:
# e.g. merge with lcov-result-merger / a cobertura merge step in the test stage,
# then:
tigergate scan --type all --upload \
--coverage-report coverage/merged.lcov
Alternatively, run a scan per package (each with its own --coverage-report)
if you scan sub-directories independently.