ci(coverage): turn on the reporting leg the Gate was already paying for - #1598
ci(coverage): turn on the reporting leg the Gate was already paying for#1598stranske wants to merge 1 commit into
Conversation
Coverage was already MEASURED on this Gate (`coverage: true`); only the reporting leg was off, because `enable-soft-gate` defaults to false in reusable-10-ci-python.yml. So every Gate run computed a coverage number and then threw it away: no coverage-trend artifact, no hotspot table, and nothing for Maint Coverage Guard to read. Report-only by construction. The soft gate runs coverage_trend.py with `--soft`, which always exits 0, so this cannot fail a PR or block a merge. Measured 78.01% from this repo's own Gate payload on 2026-08-25, against the floor of 75 already configured here, so the first reports pass and this is not a latent red. Sequenced deliberately AFTER stranske/Workflows#3251/#3253/#3254, which repaired the reporter itself: before those, an absent baseline rendered as 0.00% and every run showed a large fake improvement. Turning reporting on beforehand would have manufactured exactly that here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Warning Review limit reachedNext included review available in 13 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 71 included PR review attempts over the past 7 days set your current allowance at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Comment |
|
Hold: waiting on template sync. This turns on the coverage reporting leg. It should land only once this repo has the repaired gh api repos/stranske/Manager-Database/contents/tools/coverage_trend.py --jq .content | base64 -d | grep -c _resolve_baselineNon-zero means the fix has arrived and this is safe to merge. Why it matters: the old reporter renders an absent baseline as Sync PRs land fleet-wide in batches roughly twice daily (last here: #1597, 2026-08-24T22:16Z), so this is normal latency rather than a stall. Measured for reference: 78.01%, against the floor of 75 already configured here — so the first reports pass. |
1 participant
What
One line:
enable-soft-gate: trueon the Gate'sreusable-10-ci-pythoncall.Why
Coverage was already measured here —
coverage: truewas set. Only the reporting leg was off, becauseenable-soft-gatedefaults tofalseupstream. So every Gate run computed a coverage number and discarded it: nocoverage-trendartifact, no hotspot table, and nothing for Maint Coverage Guard to read.We were paying the cost of measuring and getting none of the value.
Risk: none
The soft gate runs
coverage_trend.pywith--soft, which always exits 0. It cannot fail a PR or block a merge. It adds artifacts and a job-summary table.Numbers
Measured 78.01% from this repo's own Gate payload (2026-08-25), against the floor of 75 already configured here. The first reports pass — this is not a latent red.
Sequencing
Deliberately after stranske/Workflows#3251, #3253 and #3254, which repaired the reporter itself. Before those, an absent baseline rendered as
0.00%and every run displayed a large fake improvement (Delta +78.01%). Turning reporting on beforehand would have manufactured exactly that output here.🤖 Generated with Claude Code