Publish this repo's own coverage report - #25
Merged
Conversation
The board reads coverage from a `coverage-report` artifact, and this repo was
one of two that never produced one - so the collector reported "no report"
about itself. It now measures coverage and uploads it in the same shape every
other repo on the board uses.
Measured: 75.4% of 845 lines. Notably not 100%, unlike the nineteen repos
already reporting, so the column finally has some variance to show. The gap is
mostly __main__.py at 30% - the refresh loops and signal handling, which the
tests do not drive.
Three details that would each have failed silently:
* The artifact name must be exactly `coverage-report`; the collector looks
for that and nothing else.
* The upload path is repo-relative (collector/_tests/coverage.xml), not
relative to the job's working-directory. defaults.run.working-directory
applies to `run` steps only, and this is a `uses` step - getting it wrong
uploads an empty artifact and the column reads "no report" while CI stays
green.
* if-no-files-found: error, so a future change that stops producing the file
fails the job instead of quietly emptying the column.
coverage source is pinned to the package in pyproject.toml rather than left to
default. Measuring the tests too would inflate the figure with lines that are
executed by definition. That denominator is deliberately narrower than
jq_local_code_lines, which counts every tracked source file - the same
distinction documented for the other repos.
Verified the collector's own parser accepts the output: _coverage() returns
(75.4, 845) on the file this job uploads.
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
1 participant
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.
The board reads coverage from a
coverage-reportartifact, and this repo was one of two that never produced one — so the collector reported "no report" about itself. It now measures coverage and uploads it in the same shape every other repo on the board uses.Measured: 75.4% of 845 lines. Notably not 100%, unlike the nineteen repos already reporting, so the column finally has some variance to show. The gap is mostly
__main__.pyat 30% — the refresh loops and signal handling, which the tests don't drive.Three details that would each have failed silently
coverage-report— the collector looks for that and nothing else.collector/_tests/coverage.xml), not relative to the job's working-directory.defaults.run.working-directoryapplies torunsteps only, and this is ausesstep. Getting it wrong uploads an empty artifact and the column reads "no report" while CI stays green.if-no-files-found: error, so a future change that stops producing the file fails the job rather than quietly emptying the column.On the denominator
coverage sourceis pinned to the package inpyproject.tomlrather than left to default — measuring the tests too would inflate the figure with lines that are executed by definition. That denominator is deliberately narrower thanjq_local_code_lines, which counts every tracked source file. Same distinction already documented for the other repos.Verified
The collector's own parser accepts the output:
_coverage()returns(75.4, 845)on the exact file this job uploads. Plus 84 tests, ruff,check-dashboard.py, scripts parse.Leaves
rhiza-taskas the last Jebel-Quant repo with no coverage report.