You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The release workflow can qualify one commit and publish a release whose live tag resolves to another commit.
At the failing review head ea66f50a16bfccfa6dd45abba526a37bd72a3c9a, the repository had no tag ruleset and immutable releases were disabled. The workflow mixed the tag-push event SHA with repeated tag-name resolution:
version-consistency used the event SHA while comparing the tag name string.
release-target resolved the live tag when that job ran.
exact-head-ci checked the exported commit, but its script could fetch the tag again.
install-gate fetched and cloned by tag name again.
publish consumed no canonical commit output and created the release by tag name without --verify-tag.
A controlled ref-move regression demonstrated the split: the target and exact-head gates continued to accept the original SHA while a fresh clone of the same tag resolved a different main descendant. Deleting the tag also left a recreation path from the default branch.
PR #486 was subsequently merged as 9a5a91a06bec50988f9cb6ea59f3e8003a08e773 with the failing head as its second parent. No v0.7.1 tag or release exists, so publication can still be withheld until this is corrected.
Required correction
Resolve one canonical release commit once and propagate that exact SHA through all four prerequisite jobs and publish.
Make every checkout, script, and fresh-clone install gate consume the canonical SHA rather than re-resolving the tag name.
Immediately before publication, fail closed unless the live refs/tags/<version> exists and still resolves to the canonical SHA.
Create the release only from an existing verified tag (--verify-tag) and explicitly bind the release target to the canonical SHA.
Add an active repository tag ruleset for v* that prevents update and deletion before publication. Immutable releases may additionally protect published releases, but are not a substitute for pre-publication tag protection.
RED/GREEN regressions must move and delete the tag between prerequisite boundaries and immediately before publication; every case must refuse.
A same-name tag resolving to a different main commit must refuse even when required CI passed on the original commit.
A missing tag must refuse; publication must never create it implicitly.
Tests must assert that all four prerequisite jobs and publish consume the same exported SHA, not merely that publish.needs lists four names.
The active tag ruleset and immutable-release setting must be queried from GitHub and recorded as release evidence.
Focused release tests, source/bench typechecks, deterministic build, full Node 24 suite, exact-head CI, and adversarial wrong-target/deleted-tag checks must all pass on the corrected head.
Scope and sequencing
Release workflow, release-gate scripts/tests, repository release-tag protection, and correction of PR #486's body only. Do not push v0.7.1, create a release, or continue unrelated release work until an independent exact-head production gate records PASS on the corrected PR.
Failure
The release workflow can qualify one commit and publish a release whose live tag resolves to another commit.
At the failing review head
ea66f50a16bfccfa6dd45abba526a37bd72a3c9a, the repository had no tag ruleset and immutable releases were disabled. The workflow mixed the tag-push event SHA with repeated tag-name resolution:version-consistencyused the event SHA while comparing the tag name string.release-targetresolved the live tag when that job ran.exact-head-cichecked the exported commit, but its script could fetch the tag again.install-gatefetched and cloned by tag name again.publishconsumed no canonical commit output and created the release by tag name without--verify-tag.A controlled ref-move regression demonstrated the split: the target and exact-head gates continued to accept the original SHA while a fresh clone of the same tag resolved a different main descendant. Deleting the tag also left a recreation path from the default branch.
PR #486 was subsequently merged as
9a5a91a06bec50988f9cb6ea59f3e8003a08e773with the failing head as its second parent. Nov0.7.1tag or release exists, so publication can still be withheld until this is corrected.Required correction
publish.refs/tags/<version>exists and still resolves to the canonical SHA.--verify-tag) and explicitly bind the release target to the canonical SHA.v*that prevents update and deletion before publication. Immutable releases may additionally protect published releases, but are not a substitute for pre-publication tag protection.cb960d0e…, 103 files / 2,271 cases, or the superseded manual sequence.Tests and acceptance
publishconsume the same exported SHA, not merely thatpublish.needslists four names.Scope and sequencing
Release workflow, release-gate scripts/tests, repository release-tag protection, and correction of PR #486's body only. Do not push
v0.7.1, create a release, or continue unrelated release work until an independent exact-head production gate records PASS on the corrected PR.