ci(coverage): turn on the reporting leg the Gate was already paying for - #1598
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. |
|
Hold released. The repaired reporter has propagated to this repo — That was the whole condition: with the old reporter this would have published Merging. |
Without config/coverage-baseline.json, tools/coverage_trend.py reports baseline_status=absent and computes NO delta, and Maint Coverage Guard has nothing to compare against -- so a coverage regression here is currently undetectable. Set at MEASURED CURRENT (78.01%, Gate payload; reporting enabled in #1598), floored to 78, with warn_drop 1.0 absorbing run-to-run jitter. Deliberately not an aspiration: a baseline above reality is red on arrival and gets switched off, and one far below it can never fail. Both failure directions are live in this fleet right now -- Fine-Art-Archive carries 25 against a real 81.45%, Workflows carries 85 against a real 76.72%. Keyed `line`: coverage_trend.py and coverage_guard.py both accept `line` or `coverage`, with `line` taking precedence. That mismatch was itself a live defect until stranske/Workflows#3251. This is a ratchet, not a target: raise it as coverage rises. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
) Without config/coverage-baseline.json, tools/coverage_trend.py reports baseline_status=absent and computes NO delta, and Maint Coverage Guard has nothing to compare against -- so a coverage regression here is currently undetectable. Set at MEASURED CURRENT (78.01%, Gate payload; reporting enabled in #1598), floored to 78, with warn_drop 1.0 absorbing run-to-run jitter. Deliberately not an aspiration: a baseline above reality is red on arrival and gets switched off, and one far below it can never fail. Both failure directions are live in this fleet right now -- Fine-Art-Archive carries 25 against a real 81.45%, Workflows carries 85 against a real 76.72%. Keyed `line`: coverage_trend.py and coverage_guard.py both accept `line` or `coverage`, with `line` taking precedence. That mismatch was itself a live defect until stranske/Workflows#3251. This is a ratchet, not a target: raise it as coverage rises. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
GitHub Actions
Inactive
|
Workflow state fingerprint for Agents Verifier. Do not edit. |
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