Skip to content

upload coverage

Upload a coverage report to Drape.

Usage

drape upload coverage <file> [flags]

Examples

drape upload coverage coverage.xml \
  --format cobertura \
  --org acme \
  --repo my-service

Flags

All global flags apply, plus:

Flag Default Description
--format (required) cobertura, lcov, or go
--path-prefix Path prefix for mapping coverage paths to repo paths
--target-branch (auto-detected) Base branch for PR diff comparison
--wait true Wait for processing and show diff results
--timeout 120 Max wait time in seconds
--total-shards Total sibling coverage shards across all CI jobs in this run. Must be ≥ 2. Enables server-side batch merging. See Batched coverage fan-in below.
--shard-key (auto-derived) Shared identifier across sibling matrix shards. Auto-derived from the CI provider's run id (GITHUB_RUN_ID, CI_PIPELINE_ID, etc.) when unset.

Batched coverage fan-in

When multiple shards produce coverage for the same commit (matrix jobs, multiple test suites feeding one snapshot), each shard calls drape upload coverage --total-shards N. The server holds uploads pending until N shards arrive, then merges into a single CoverageSnapshot.

# Each matrix shard runs:
drape upload coverage coverage-${SHARD}.xml \
  --format cobertura \
  --group python \
  --total-shards 3 \
  --wait

The CLI automatically correlates shards by (provider_run_id, run_attempt, group) read from CI env vars (GITHUB_RUN_ID, GITHUB_RUN_ATTEMPT). No GitHub Actions output-passing between jobs needed.

Partial finalization: if a shard crashes and fewer than N arrive, the server finalizes with whatever came in after a 5-minute timeout. The result's partial flag signals this — the CLI logs "⚠️ Partial coverage" to stderr and exits 0 so CI stays green.

Late arrivals: if a slow shard finishes after the partial finalization, its upload still lands (200 OK) and the server re-merges within ~15s. If the CLI is still in its --wait window (default 120s), it picks up the refreshed result and the PR comment updates in place via drape-action's sticky comment.

PR Coverage Diff

For PR builds, the CLI auto-detects the PR number and target branch from CI environment variables. The server compares your PR's coverage against the base branch and reports:

  • Coverage regression — previously-covered lines that lost coverage (and weren't modified in the PR)
  • New code coverage — percentage of new/changed lines that are covered

Example output:

Coverage Summary
  Coverage rate: 86.20%
  Files:         42

Coverage Diff (PR #42)
  Base:      85.50%
  Head:      86.20%  (+0.70%)
  New code:  92.00%  (23/25 lines)
  Regressed: 0 lines
  Result:    PASSED

Exit Codes

Code Meaning
0 Success
3 Upload error
5 Parse error
6 Coverage regression — coverage diff check failed