Repository navigation
fix(render): avoid action-specific baseline and artifact claims in CLI reports #137
Description
Observed behavior
The new PR-build coverage report from #135 (source issue #134) intentionally supplies no baseline and uploads a distinct coverage-pr-build artifact. Its posted comment nevertheless includes two renderer defaults:
- It says a main baseline is missing and that per-file deltas will appear after a baseline is published. This job never retrieves a baseline, so that promise does not apply. The release job already had a baseline and posted deltas in its separate comment.
- It says a full per-file summary is attached as
coverage-summary. That artifact belongs to the release job, not this PR-build report. The PR-build artifact contains LCOV and the rendered comment, not a full per-file summary.
The successful run uploaded both artifacts. The PR-build job took 1m22s and all checks passed; this is a report-guidance defect, not a failed coverage gate.
Cause and consequence
src/render.rs emits action-specific assumptions whenever a baseline or artifact URL is absent: the no-baseline paragraph around lines 250–256 and render_footer around lines 544–561. Direct CLI use inherits the same claims, even outside GitHub. Passing --run-url alone does not produce a run link because the renderer only renders it when artifact_url is present.
Readers are directed to the release's artifact when they want the PR-built binary's results, and are told to wait for baseline deltas this job will never compute. The workflow's introductory explanation contradicts the renderer's paragraph.
Proposed next action
Make absent-baseline/artifact guidance accurate for direct CLI use: describe the missing baseline report without promising a future action-managed baseline, and omit claims about an uploaded summary when no artifact URL or explicit artifact metadata was supplied. Preserve useful run links independently of artifact links. In the PR-build workflow, link to its actual uploaded artifact if appropriate, labeling it according to its contents. Keep action integrations working when they explicitly supply a summary artifact URL.
The exact API/CLI choice is open; avoid text filtering in the workflow to hide renderer assumptions if a general renderer fix can address them.
Acceptance criteria
- A CLI markdown render with no baseline does not promise automatic future deltas or assume a main-branch artifact lookup.
- With no artifact metadata, the report does not claim a full per-file summary has been uploaded under a hard-coded name.
- A supplied run URL remains usable even without an artifact URL; explicit artifact links still render correctly.
- The PR-build comment points readers to its own report/artifact and accurately describes those contents.
- Renderer regression tests cover missing baseline/artifact metadata and the run-only URL case; any changed public flags/options are documented.
Out of scope: adding baseline retrieval/recompute to the PR-build job, making that job required, changing coverage thresholds, or changing the external action repository.
Activity
newhoggy commentedon Oct 10, 2026
Implementation plan
Goal and acceptance criteria
Make CLI Markdown reports accurate when no baseline or artifact metadata is supplied: no automatic future-baseline promises or assumed main artifact lookup, no fabricated coverage-summary upload, independent run links, and a PR-build comment that links to its own artifact and describes its LCOV/Markdown contents. Preserve explicit full-summary artifact links and cover the renderer behavior with regression tests.
Approach
Use the existing options without introducing a new CLI flag or library field. Missing baseline guidance will describe unavailable comparisons; an absent/empty artifact URL will omit artifact guidance. Run URLs will render independently. Keep the existing explicit artifact URL label for action integrations supplying full per-file summaries. The PR-build workflow will append its own accurately labeled artifact link using upload-artifact's actual artifact-url output after upload. Its archived comment retains the renderer's run link; the posted comment and run summary gain the direct artifact link. This avoids a circular upload/render dependency, fabricated artifact URLs, and workflow text filtering.
Changes, in order
src/render.rs: replace the absent-baseline paragraph; handle artifact-only, run-only, both and neither footer cases, including empty URL values; update/add regression tests..github/workflows/ci.yml: give the PR-build upload step an ID, append its returned artifact URL with an LCOV/Markdown label, then publish the run summary and existing sticky comment before gates.docs/reference.md, CLI/library option documentation if needed,README.md, andCONTRIBUTING.md: document absent-metadata and independent-link behavior, remove the example's implicit artifact claim, and explain the archived versus posted report link.Tests and verification
All commands target WT=/Users/jky/wrk/work-trees/patchcov/issue-137-render-report-guidance explicitly via --manifest-path, workdir, or absolute paths.
cargo test --manifest-path "$WT/Cargo.toml" --locked render::testsfor regression cases.actionlint "$WT/.github/workflows/ci.yml"for workflow expressions and shell.cargo fmt --manifest-path "$WT/Cargo.toml" --check.cargo test --manifest-path "$WT/Cargo.toml" --locked --all-targetsandcargo test --manifest-path "$WT/Cargo.toml" --locked --doc.cargo clippy --manifest-path "$WT/Cargo.toml" --locked --all-targets -- -D warnings.cargo run --manifest-path "$WT/Cargo.toml" --locked -- lint-markerswith workdir WT.cargo +1.88.0 test --manifest-path "$WT/Cargo.toml" --locked --all-targetsandcargo +1.88.0 test --manifest-path "$WT/Cargo.toml" --locked --doc.RUSTDOCFLAGS='-D warnings' cargo doc --manifest-path "$WT/Cargo.toml" --locked --no-deps --document-private-items.Commit, review the committed diff once, fix confirmed findings, fetch/rebase on origin/main and repeat verification. Push and open the PR; inspect hosted checks/report if they complete in-session.
Risks, assumptions and out of scope
The existing artifact-url option continues to mean a full per-file summary. Arbitrary artifact labeling stays with the workflow, which knows its contents. The archived Markdown cannot link to its own not-yet-created upload, but includes the run link; the published comment and summary will contain the actual upload URL. Hosted upload/comment behavior and fork token behavior need GitHub CI verification. No baseline retrieval, threshold/required-check changes, external action edits, merge, or unrelated issue changes.