ci(auto-release): dispatch release.yml instead of pushing tag - #4
Merged
Conversation
Tag pushes authenticated by GITHUB_TOKEN do not trigger downstream workflows (GitHub's recursion-prevention rule), which silently breaks the Cargo.toml bump -> auto-release -> release.yml chain. The tag ends up on the remote but no binaries build. Switch to dispatching release.yml directly. The release workflow already supports workflow_dispatch and creates the tag itself in that path, so there is no downstream trigger to be blocked. Pin the dispatch to GITHUB_SHA so the release is cut from the exact commit that bumped Cargo.toml, guaranteeing the tag/Cargo.toml validation in release.yml passes even if main advances in the interim. - Remove `git tag`/`git push` from this workflow; downgrade permissions from contents:write to contents:read + actions:write. - Check tag existence via the GitHub API rather than the local clone; the API is authoritative for 'has this release already been cut'.
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.
Summary
Fix the silent failure in the
auto-release.yml→release.ymlchain. Tag pushes authenticated byGITHUB_TOKENdo not trigger downstream workflows (GitHub's recursion-prevention rule), so a version bump merge would create thevX.Y.Ztag on the remote but never produce a release. Discovered during the v1.1.1 cut — the tag landed, butrelease.ymlnever fired, so the release had to be re-cut manually by deleting the remote tag and re-pushing it under a human's credentials.The fix: stop creating the tag in this workflow. Instead,
gh workflow run release.yml -f version=X.Y.Z --ref $GITHUB_SHA.release.ymlalready has aworkflow_dispatchcode path that creates the tag itself, and since it's the running workflow at that point rather than a downstream trigger, the recursion block doesn't apply.Changes
git tag+git push origin $TAGwithgh workflow run release.yml.$GITHUB_SHA(the exact version-bump commit) so the Cargo.toml-vs-tag validation inrelease.ymlis guaranteed to pass even ifmainadvances between auto-release firing and the dispatch.gh api repos/.../git/refs/tags/$TAG) rather thangit rev-parseon the local clone — the API is authoritative for "has this release already been cut".contents: write→contents: read, addactions: write(needed bygh workflow run).Why not use a PAT instead?
A PAT on the tag push would also work (
GITHUB_TOKENrecursion block doesn't apply to PATs), but it adds secret management overhead and a rotation surface. The dispatch approach keeps everything within the defaultGITHUB_TOKENand shrinks the blast radius.Test plan
release.yml, and a release is cut end-to-end.release.ymlnormally.