Release-cut CI check: verify client/package.json version matches git tag #157
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Background
PR #156 (#147 version build-stamp) opportunistically catches a substrate-of-record gap: client/package.json
versionwas never bumped from 0.0.1 → 1.0.0 at the v1.0.0 release-cut. Tag + Forgejo release marked v1.0.0; manifest stayed 0.0.1; mismatch.Shipwright flagged in PR #156 body: "optional release-CI-check follow-up offered."
Severity: LOW substrate-of-record discipline
Doesn't affect runtime; affects substrate-of-record-honesty (manifest version should match git tag + Forgejo release version).
Proposed scope
CI check that verifies on a release tag:
versionTriggers on tag-push events or release-creation events.
Acceptance criteria
git push origin v*or release-create event)versionfieldFix-direction
Small CI script in client/.forgejo/workflows/release-check.yml (or similar). Probably ~20 lines.
Cross-refs
Anchor
2026-06-24 02:55 — Shipwright surfaced during #147 build-stamp injection: client/package.json version 0.0.1 vs git tag v1.0.0 mismatch detected and corrected in PR #156. Filed per substrate-for-decision discipline (durable-tracker-home for the gap before it evaporates).
quartermaster referenced this issue from frankenbit/release-toolkit2026-06-24 13:13:21 +02:00
Closing — satisfied by release-toolkit adoption (#168 → v1.1.0 cut 2026-06-26)
Closing as done, per operator confirmation 2026-06-26. The bug class this tracker wanted to catch — manual-cut tag-vs-
client/package.jsonversion drift — can no longer fire via cellblock's normal release flow.What changed
PR #168 adopted frankenbit/release-toolkit. Cellblock's first cut via the toolkit (v1.1.0, published 2026-06-26 22:29) ran end-to-end:
release-prep.shupdatesclient/package.jsonin the rolling PR's prep commit (chore(release): prepare vX.Y.Z) to the next versionmanifest-check.ymlvalidatesversion_files↔ manifest ↔ CHANGELOG on every PRdraft-release.shcreates the tag at the rolling PR's merge SHA, which already hasclient/package.jsonat the correct versionclient/package.jsonare guaranteed to match by construction at cut timeHow this differs from the original AC
The original AC #1 called for "CI job runs on tag push" — a defense-in-depth check that catches manual cuts. The toolkit's approach is structurally stronger: it makes the manual-cut path the exception rather than the default, by orchestrating tag creation through the rolling-PR mechanism.
The bug PR #156 opportunistically caught (manifest stayed 0.0.1 while tag was 1.0.0) was a manual-cut artifact. With the toolkit driving cuts, this exact mismatch can't happen on the normal flow.
Remaining defense-in-depth gap (not addressed by this closure)
If someone bypasses the toolkit (e.g.,
git tag v1.2.0 && git push --tagsoutside the workflow), there's no tag-push-event check to catch the bypass. The toolkit'smanifest-check.ymlruns on PR events, not on tag-push events. This is a separate scope; not opening a follow-up tracker per operator's preference unless the gap surfaces empirically.Refs