ci: tag push fires release-check tag-integrity; retire empty-commit retrigger - #59
Conversation
Tag pushes now fire release-check via a new tag-integrity job that checks out the tagged tree (ref: github.ref_name) and fails when the tree's VERSION does not equal the tag name with the leading v stripped. The tag push becomes the green proof after a release; tag-current is unchanged and also runs on tag pushes.
The empty-commit re-trigger was a junk commit pushed directly to master, bypassing PR-required branch protection, so that a check triggered only on master pushes would get a second reading after the tag landed. The tag-integrity job makes the tag push itself fire release-check, so the proof rides the push that was already required. No empty commit, no direct push to master.
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
APPROVE — Standards PASS / Spec PASS. 0 blocking, 1 non-blocking LOW. Base pinned: reviewed DoD items — all verified:
Spec (PR description) vs registry: "no-bump content PR, 2 files, VERSION stays 0.9.2" — confirmed against Non-blocking:
Good, tightly-scoped change; the check verifies tag content (the silent failure mode |
1 participant
What
Retires the empty-commit re-trigger remedy for
release-check. The tag push itself now fires the workflow and is the green proof after a release.Why:
release-checkonly triggered on pushes tomaster, but the tag lands after the merge (merge gate: coder → reviewer → maintainer tail that merges, tags, re-triggers). Every release had a red window between merge and tag, and the documented remedy —git commit --allow-emptypushed directly to master — bypasses PR-required branch protection for a junk commit. Live instance: PR #58 (v0.9.2) merged with no tail card dispatched; the tag was pushed manually at 11:4x and the next master push went green without the empty commit.Changes (2 files)
.github/workflows/release-check.ymlon.pushgainstags: ['v*'](master trigger kept, single push block).tag-integrityjob (if: startsWith(github.ref, "refs/tags/v")): checks out the tagged tree and fails if the tagged tree'sVERSIONdoes not equal the tag name (leadingvstripped). Verifies tag content, not just existence —tag-currentonly proves the tag exists on origin; this catches a tag pointed at the wrong commit, the silent failure mode the current check cannot see (F10 class: verify the effect, not the handle).tag-currentjob is byte-identical (pure addition; it also runs on tag pushes, which is harmless — it re-checks master's VERSION↔tag).AGENTS.md— two spots: the release-convention paragraph (empty-commit remedy retired; tag push is the green proof) and merge-gate step 3 (tail "pushes the tag — the tag push fires release-check (tag-integrity) which is the green proof. No empty commit.").No VERSION bump, no CHANGELOG change — no-bump content PR;
VERSIONstays 0.9.2.Verification
Local (done):
::error::line naming both values; v0.10.0/VERSION=0.10.0 PASS.bash test/smoke.sh60 passed 0 failed (baseline pre-change identical).Live (two-phase — must run in the maintainer tail AFTER this PR merges, because the new workflow only exists on master then):
v0.9.99-testat the then-current master commit →tag-integrityrun must FAIL (VERSION=0.9.2 ≠ 0.9.99). Record run URL, then delete the tag.v0.9.2— the SAME existing tag object (re-push the ref; identical SHA = zero release-history change).tag-integrityrun must PASS. Constraint: only if no box has pulled v0.9.2 since the tag push (updates are manual — check first; if any box pulled, skip this phase and note why).Tail semantics (pinned)
MERGE-ONLY tail: no VERSION change, no tag, no re-trigger. The merge push runs
tag-currentand stays green (v0.9.2 is on origin). The two-phase live verification is the tail's job, per the plan above.