feat(_release-rust): draft→upload→publish for immutable releases#110
Merged
Conversation
GitHub immutable releases lock a release's tag and assets at publish time — assets can no longer be added, modified, or deleted once published. The prior flow created the release already-published and uploaded assets afterward, which is incompatible: the post-publish uploads would be rejected. Always create the release as a draft, attach every asset, then flip it to published as the final step (unless release_draft asks to stop at the draft for manual review). The publish transition still fires the `release: published` event downstream workflows depend on, and the final state is identical for repos without immutability enabled, so this is backward-compatible. Refs kunobi-ninja/kache#481
emmanuelm41
added a commit
to kunobi-ninja/kache
that referenced
this pull request
Jul 1, 2026
This repo will have GitHub immutable releases enabled — publishing a release locks its tag + assets. That requires the reusable release workflow to create a draft, attach all assets, then publish (see Zondax/_workflows#110), which the pinned @v10 tag now carries. Document that constraint on the release job so the pin isn't rolled back to a tag predating the draft→publish flow. No functional change (pin stays @v10). Closes #481
emmanuelm41
added a commit
that referenced
this pull request
Jul 1, 2026
#111) The draft→upload→publish change (#110) made the publish transition (gh release edit --draft=false) run as GITHUB_TOKEN / github-actions[bot]. GitHub suppresses workflow triggers for events produced by GITHUB_TOKEN, so the resulting release: published event was sterile — downstream release-triggered workflows (crates publish, package publish) never ran. Publish with the caller's release PAT (secrets.pgp_signer_token) when provided, falling back to GITHUB_TOKEN. A PAT-authored publish cascades, restoring the pre-#110 behavior where the direct create-publish (also authored by the PAT) triggered downstream release workflows. Refs kunobi-ninja/kache#481
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Change the reusable Rust release workflow's
releasejob from create-published-then-upload to create-draft → upload assets → publish.Why
GitHub immutable releases (GA) lock a release's git tag and assets at publish time — once published, assets can't be added, modified, or deleted. The prior flow published first (
gh release createwith no--draft) then uploaded assets, so with immutability enabled the post-publishgh release uploadwould be rejected and every release would break. GitHub's required flow is: create draft → attach all assets → publish. This PR implements exactly that.Backward-compatible
The final state is an identical published release with all assets attached — repos without immutability enabled see no functional difference. Because of that, the plan is not to split old/new behavior across tags: after merge, both the
v10andv11moving tags advance to this commit (they currently point at the same commit and stay in lockstep). Consumers on either tag get the new flow; nobody is left behind.Details:
gh release edit --draft=false) still fires therelease: publishedevent downstream workflows trigger on — now at the end of the job rather than the start.release_draft: truestill works: the draft is left unpublished for manual review (auto-publish skipped). Description updated to match.--latest=falseattributes are set at create time and persist through the publish transition.Context
Enables immutable releases for kunobi-ninja/kache — refs kunobi-ninja/kache#481 (kache-side doc PR: kunobi-ninja/kache#482).