Repository navigation
0.3.10: a shard matches its own package, and zero matches says so - #69
Merged
Merged
Conversation
A coverage_map shard written by `pytest --cov` from its package directory keys its files as `src/m.py`. The lookup asked the shard for `packages/alpha/src/m.py` only, so the per-package setup the map exists for scored every function at 0% coverage. - MultiCoverageData.lookup tries the repository-relative path first, then the path relative to the shard's prefix, as an exact match. - RiskReport counts the Python files it looked up in a present coverage report and how many had no entry. When none matched, scan, baseline, check, diff, explain, and the pytest plugin print one warning, and the scan summary line, the markdown report, and the Baseline: line of every check format carry "coverage matched 0 of N scanned files". Scores drop where a shard matched nothing before. The verdict, the scoring model version, and all nine JSON schemas don't change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
riskratchetRegressions: 2 · New above threshold: 0 · Regressed: 0 · Existing above threshold: 0 · Component regressed: 2 · Above threshold: 0
New functions (7)
Unchanged functions (565)
|
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.
A
coverage_mapshard written from its package directory now matches, and a coverage report that matches no scanned file says so. This is PR 2 of 0.3.10, based on master after #68.The findings
These were reproduced on
c1f64d4. The fixture is a monorepo withpackages/aandpackages/b, a[tool.riskratchet.coverage_map]table with one coverage file (a shard) per package, and each shard written bypytest --covrun from the package directory.src/amod.py.MultiCoverageData.lookuppicks the shard by prefix and then asks it forpackages/a/src/amod.py. Every function scores 0% line coverage.coverage_statusreadspresentwhenever a report loads.checkprintsNo risk regressions detected., the PR comment shows 0% on every row, and only stderr has one warning per file.doctorreports the case ascoverage-overlap, and no other command does.Together these mean a monorepo that follows the README has a gate that ignores coverage: a PR that deletes every test moves no score.
The fix
MultiCoverageData.lookuptries the repository-relative path first, then the path relative to the shard's prefix. The second lookup is exact (CoverageData.lookup_exact), sopackages/alpha/core.pycan't pick up an unrelatedvendored/core.pyby basename.RiskReportgainscoverage_checked_filesandcoverage_unmatched_files: the Python files with at least one function that the engine looked up in a present report, and how many had no entry.DiffReportcarries the resulting note, because thecheckrenderers get the diff and never the report.scan,baseline,check,diff,explain, and the pytest plugin print one warning. The scan summary line, the markdown report's**Coverage:**line, and theBaseline:line of everycheckformat carrycoverage matched 0 of N scanned files.What changes for an adopter
Scores drop in a repository whose shards matched nothing:
coverage_gapandbranch_gapfall to their real values.checkreports those functions as improved, so no gate fails. The CHANGELOG states this under Changed and says to regenerate the baseline after upgrading.The following don't change: the gate verdict, exit codes,
SCORING_MODEL_VERSION, and all nine JSON schemas.coverage_statusstayspresent, and the two new fields aren't serialized. The note is a count, so it's safe under redaction.Tests
18 new tests in
tests/test_coverage.py,tests/test_coverage_overlap.py, andtests/test_pytest_plugin.py. Against thev0.3.9src/, 5 fail directly and the 10 intests/test_coverage_overlap.pyfail at import. The other 3 guard behavior that must stay the same: the repository-relative key wins, a path outside every prefix doesn't match, and an empty prefix has no second spelling. The suite has 1391 passed and 2 skipped, with 93.28% coverage.Baseline bump rationale
regenerate-baseline.ymlregenerated the baseline in CI (run37102003419, commitfdb19bd). It goes from 567 to 574 entries, and thescoringblock doesn't change. 29 of the 567 existing entries change score. The largest rise is +3.25, underfail_regression_above = 5.models.py::coverage_overlap_noteat 5.8.cli.py,engine.py,models.py, andsummary.py.MultiCoverageData.lookup+3.25 (one more branch for the second lookup),engine.py::analyze+3.12 (the two counters),pytest_sessionfinish+2.39,diff+1.25,_summary_line+0.32, andbaseline_line+0.19.🤖 Generated with Claude Code