ci: stamp coverage comment with commit SHA + revision number #78
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "worktree-coverage-comment-provenance"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Why
The sticky coverage comment gave no indication of which commit its numbers belonged to. A reviewer (human or agent) could not tell whether the percentages reflected the current head or a stale prior push — which is exactly what happened in PR #77: the comment showed RegionBriefing 100%/95% from
bd1a82e, but the head had already moved to406537ewith two new commits.What changes
.github/scripts/post-coverage-comment.sh— the comment body now carries a provenance header:#1,#2, …), parsed from the previous comment body and incremented on each update. First post (or migration from old comments without a revision line) starts at#1..github/workflows/ci.yml— passes${{ github.event.pull_request.head.sha }}as a new 6th argument to the script.Example output
Migration
Old comments without a
Revision:line are handled gracefully — the script treats them as revision #1 and continues incrementing from there.Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.9%
Orihon.Domain - 100%
Orihon.Infrastructure - 95.6%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 93.3%
Orihon.UseCases - 96.5%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh~! A provenance stamp for the sticky coverage comment! ♪ This is exactly the little headache that bit us in PR #77 — the comment swore up and down it was
RegionBriefing 100%/95%frombd1a82e, but the head had already danced ahead to406537e. Numbers without a commit are lies dressed up as percentages, fufu~ Now the comment names its own source of truth. I love this kind of traceability fix — it's the sort of thing that makes a reviewer's heart go pitter-patter ♡I tore the revision-parsing logic apart with a mock harness. Let me show you the receipts~
Verdict: ✅ Looks good to me~
✅ What I liked~
Revision:line →PREV_REVis empty →[ -n "$PREV_REV" ]is false →REVstays1. Tested with a real old-format body (just<!-- coverage-comment -->+ table, no revision). Graceful, exactly as the PR body promises. fufu~ ♡#3→4,#99→100,Revision:#5(no space)→6. The sed regexRevision:.*#\([0-9][0-9]*\)is permissive in the right way — handles the script's own**Revision:** #Nformat AND reasonable variants.jq -r '...[0] // empty'+ double guard. Fetching the full existing comment object (instead of just.id) and then extracting.idand.bodyseparately is sharp — one API call, two fields, and the[ -n ] && [ != "null" ]belt-and-suspenders handles jq's null-on-no-match. Clean~<!-- coverage-comment -->is the very first line ofBODY, so the sticky-commentcontains($m)lookup will still find it. The provenance block sits inside the marker, not before it. Correct ordering.cut -c1-7. Standard 7-char git short SHA, matches the PR body's406537eexample exactly. Backtick-wrapped in markdown for that pretty monospace look~$1–$6).${{ github.event.pull_request.head.sha }}is the push SHA (not branch tip), which is precisely what the PR body claims — "always the exact push the coverage ran against." Thehead.shavsafterdistinction matters here and they picked the right one.100644→100755. Now it's actually executable. Small but correct.<sha>as 6th arg — matches reality. I always check this and it's right ♪💡 Little ideas (non-blocking)~
post-coverage-comment.sh:47— sed could emit multiple values if body has >1 matching line. The pipelinesed -n 's/.*Revision:.*#\([0-9][0-9]*\).*/\1/p'prints one captured number per matching line. IfPREV_REVever holds two values (e.g.2\n5),REV=$((PREV_REV + 1))throws a syntax error underset -euo pipefailand the script dies.Revision:line per comment, and ReportGenerator'sMarkdownSummaryGithuboutput is a coverage table that never contains the word "Revision." So from the script's own output, no. The only trigger would be a human manually editing the sticky comment to add a secondRevision: #Nline — extremely unlikely, and arguably "don't do that."head -1—sed -n '...' | head -1. One character of defense-in-depth, zero behavioral change for the realistic path. Optional~post-coverage-comment.sh:52— shellcheck SC2016 (info-level, false positive). Shellcheck flags the single-quotedprintfformat string because it contains backticks. But those backticks are literal markdown code-span delimiters (`170ddbe`), not command substitution — they're correctly literal inside single quotes, and the%s/%dplaceholders are expanded byprintfitself (not bash). Nothing to fix; I'm noting it only so you know I ran shellcheck and this is the sole finding, and it's a known false positive for this pattern.Automated review by Jibril · 2026-07-27
CI/CD: absent for head
170ddbe(PR just opened, 0 comments pre-review) · Local checks: bash syntax OK, shellcheck 0 errors (1 SC2016 info/false-positive), revision-parse logic verified across 8 mock scenarios (migration→1, #3→4, #99→100, #0→1, no-#→1, null-guard✓)