[fgrosse]

Refs #109 (the remaining fallback issue will be addressed in a follow-up PR)

Problem

The baseline coverage was always taken from the first result of gh run list --limit=1 on the target branch. On busy repositories this API can return stale runs. The report then either compared against old code, or said the baseline artifact was unavailable even though a recent one existed.

Changes

Baseline selection (scripts/github-action.sh, action.yml)

The baseline run is now selected in this order:

1. The run given via the new baseline-run-id input, if set. An unknown run ID fails the job.
2. The latest successful run for the new baseline-sha input, which defaults to github.event.pull_request.base.sha.
3. The latest successful run on the target branch, as before. If a SHA was given, this fallback emits a warning.

Setting baseline-sha: "" restores the previous behavior. This is a behavior change: by default, PRs are now compared against their base commit instead of the latest run on the target branch.

Diagnostics

• The selected run is logged with its ID, commit, age and URL.
• Warnings now distinguish between "no baseline run found", "base commit has no run, using latest" and "artifact of the selected run could not be downloaded".

PR comment

• If the report does not compare against the base commit, a single line [!CAUTION] callout at the top explains why.
• New CLI flags -baseline-commit, -baseline-run-id and -baseline-run-url name the baseline at the top of the details section.
• The details section is renamed to "Coverage details" and no longer uses headings, to avoid mixing many text sizes.

Example with a fallback:

> [!CAUTION]
> No coverage for base commit 3ab52af was found, so this report compares against 2eb52af (latest run on `main`)

### Merging this branch will **increase** overall coverage
...
<details>

<summary>Coverage details</summary>

<sub>Compared to base commit 2eb52af (run [#8221109494](...))</sub>
...
</details>

Testing

• go test ./... with new tests for the baseline line, and existing tests updated for the new details layout.
• bash -n and shellcheck on the script.
• Ran the script end-to-end with a mocked gh for the base SHA, fallback, missing artifact, no run and explicit run ID cases.
• Tested in a real GitHub Actions run in Demo: coverage report comment for the go-coverage-report README prioqueue#6, which installs the binary from this branch. The baseline was found by the base commit and the comment renders as expected.

Notes

• Using the new action script with an older pinned version of the binary fails on the unknown -baseline-* flags. The default version is bumped on release.
• screenshot.png in the README is updated with the new layout, taken from Demo: coverage report comment for the go-coverage-report README prioqueue#6.

[Copilot]

Copilot review overview

🟡 Changes recommended

The default binary is incompatible with the new flags, and baseline metadata and caution handling still have unresolved correctness issues.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2 · 2

Open (4)

• Default binary lacks required baseline CLI flags · New
• Pinned default binary is incompatible with baseline flags · New
• Label selected SHA as baseline commit, not base commit · New
• Missing caution for explicit runs differing from PR base · New

What changed in this PR

Updates baseline coverage selection to prefer the PR base commit and adds diagnostics and baseline metadata to reports.

Changes:

• Adds baseline-run-id and baseline-sha inputs with fallback behavior.
• Adds baseline run logging, warnings, and caution callouts.
• Updates report layout, documentation, changelog, and tests.

File	Summary
scripts/​github-action.sh	Implements baseline discovery, diagnostics, and report integration.
README.md	Updates baseline behavior and usage documentation.
cmd/​go-coverage-report/​report.go	Renders baseline metadata in reports.
cmd/​go-coverage-report/​report_test.go	Updates and expands report output tests.
cmd/​go-coverage-report/​main.go	Adds baseline CLI flags.
CHANGELOG.md	Documents the behavior changes.
action.yml	Adds baseline inputs and action configuration.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Two moderate baseline-selection issues and one documentation nit remain unresolved.

Review effort: Lite
Findings: None

Resolved since last review (4)

• Pinned default binary is incompatible with baseline flags
• Default binary lacks required baseline CLI flags
• Missing caution for explicit runs differing from PR base
• Label selected SHA as baseline commit, not base commit

[fank]

Thanks for addressing this so quickly. The exact-base-SHA lookup, explicit run override, and diagnostics are all strong improvements, and I verified that the test suite and ShellCheck pass on the current head.

I think one correctness gap remains before the original failure mode is fully covered: the fallback at scripts/github-action.sh:145-147 still uses the same broad gh run list --branch … --status=success --event=… --limit=1 lookup that can return a stale result.

The new default path is correct when the base commit has a completed successful run. But there are ordinary cases where it does not:

• the base commit's run failed or was cancelled;
• it is still running when the report job reaches baseline selection;
• it completed without the expected artifact;
• the exact-SHA listing transiently returns no result.

In those cases the action falls back to find_baseline_run --branch="$TARGET_BRANCH". Because that broad query is the source of the intermittent stale selection, the fallback can still choose a substantially older run. The new caution and run-age diagnostics make the outcome visible, which is valuable, but the resulting delta can still include unrelated changes—or lose the baseline when the stale run's artifact has expired.

Would you consider making the fallback select the nearest usable ancestor of REQUESTED_BASELINE_SHA instead? For example:

1. Start at the requested base SHA and inspect a bounded number of first-parent ancestors.
2. Look up runs by exact head_sha/commit.
3. Re-check SHA, branch, event and conclusion client-side.
4. Continue when the run or coverage artifact is unavailable.
5. Only use the broad “latest branch run” behavior when baseline-sha: "" explicitly opts into the legacy semantics.

A smaller alternative would be to retrieve multiple branch candidates and filter/sort them client-side, but that still cannot guarantee the baseline is at or before the tested base. Walking ancestors preserves the intended meaning of the coverage delta and handles gaps from failed/cancelled runs.

I would treat this as a meaningful improvement even without that change: the primary path should solve most occurrences. But I would not consider the stale-baseline failure fully closed while the automatic fallback still depends on the original broad query.

[henry-hived]

I am also coming up against this issue. I found that this CLI request always found the most recent run

gh run list --workflow=test.yml --limit 50 \
  --json databaseId,headBranch,event,conclusion \
  -q '[.[] | select(.headBranch=="main" and .event=="push" and .conclusion=="success")][0].databaseId'

Vs this which often returns data 14+ days old gh run list --status=success --branch=main --workflow=test.yml --event=push.

I agree the PR you have here is a significant improvement. Could the fallback be picked up in a later version?

[fgrosse]

Thanks @fank and @henry-hived for the thorough feedback and for testing this.

You're right that the fallback still relies on the broad gh run list query that caused #109. I'll merge this PR as is, since the new default path already covers the common case, and I've changed "Fixes #109" to "Refs #109" so the issue stays open until the fallback is fixed too.

In the follow-up I plan to combine both of your suggestions:

1. Fetch a bounded list of ancestors of the base commit.
2. List recent runs of the baseline workflow without the server-side --status/--branch/--event filters and filter them client-side, since @henry-hived found that the filtered queries are the ones that return stale results.
3. Use the nearest ancestor with a successful run, and move on to the next candidate if its coverage artifact can't be downloaded.
4. Keep the "latest run on the target branch" behavior only when baseline-sha: "" opts into it.

This also covers base commits whose run failed, was cancelled or is still in progress.

[github-actions]

Merging this branch will decrease overall coverage

Impacted Packages	Coverage Δ	🤖
cmd/go-coverage-report	64.34% (-0.37%)	👎

Coverage details

_{Compared to commit 6093ed4 (run #36230694596)}

Changed File	Coverage Δ	Total	Covered	Missed	🤖
cmd/go-coverage-report/main.go	0.00% (ø)	56 (+5)	0	56 (+5)
cmd/go-coverage-report/report.go	85.16% (+0.49%)	155 (+5)	132 (+5)	23	👍

Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code.

Changed unit test files:

• cmd/go-coverage-report/report_test.go