Skip to content

Bind release publication to one protected immutable tag target #499

Description

@MongLong0214

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-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

  1. Resolve one canonical release commit once and propagate that exact SHA through all four prerequisite jobs and publish.
  2. Make every checkout, script, and fresh-clone install gate consume the canonical SHA rather than re-resolving the tag name.
  3. Immediately before publication, fail closed unless the live refs/tags/<version> exists and still resolves to the canonical SHA.
  4. Create the release only from an existing verified tag (--verify-tag) and explicitly bind the release target to the canonical SHA.
  5. 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.
  6. Correct PR Release 0.7.1 — the tier 0.7.0 announced, actually reachable #486's stale body evidence and sequencing description so it no longer names cb960d0e…, 103 files / 2,271 cases, or the superseded manual sequence.

Tests and acceptance

  • 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions