ci(coverage): set the coverage baseline at measured current (78%) - #1601
Merged
Conversation
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>
|
Warning Review limit reachedNext included review available in 47 minutes. View limit detailsLimit details: You’ve used the included review currently available. Your 83 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 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why this file matters
Without
config/coverage-baseline.json,tools/coverage_trend.pyreportsbaseline_status: absentand computes no delta — and Maint Coverage Guard has nothing to compare against. A coverage regression in this repo is currently undetectable.The number
Measured 78.01% from this repo's own coverage payload, floored to 78, with
warn_drop: 1.0absorbing run-to-run jitter.Set at measured current, not at an aspiration — deliberately. Both failure directions are live in this fleet right now:
A baseline above reality gets switched off; one far below it never fires. Same defect, opposite directions.
Keyed
lineBoth
coverage_trend.pyandcoverage_guard.pyacceptlineorcoverage, withlinetaking precedence. That mismatch was itself a live defect until stranske/Workflows#3251, under which this repo's trend silently scored0.0.It's a ratchet
Raise it as coverage rises. It is not a target, and it should never be lowered to make a run pass.
🤖 Generated with Claude Code