ci: use GitHub App token for checkout in build-release to fix tag push with workflows scope#20157
Merged
lystopad merged 2 commits intoMar 25, 2026
Merged
Conversation
…h with workflows scope GITHUB_TOKEN lacks the `workflows` scope, which GitHub requires when pushing a tag that points to a commit touching .github/workflows/ files. This caused the release workflow to fail at the tag push step with: "Unable to determine if workflow can be created or updated due to timeout; `workflows` scope may be required." Fix: generate the GitHub App token (already used in publish-release) in the build-release job as well, and pass it to actions/checkout so that subsequent git push operations use it instead of GITHUB_TOKEN.
awskii
approved these changes
Mar 25, 2026
lystopad
added a commit
that referenced
this pull request
Mar 25, 2026
…h with workflows scope (#20157) ## Summary When a release is triggered from a commit that touches `.github/workflows/` files, GitHub requires the `workflows` scope to push the git tag. `GITHUB_TOKEN` does not have this scope, causing the tag push to fail: > `! [remote rejected] v3.3.10 -> v3.3.10 (Unable to determine if workflow can be created or updated due to timeout; workflows scope may be required.)` Real-world failure: https://github.com/erigontech/erigon/actions/runs/23549095701/job/68557718510 ## Fix Generate the GitHub App token (already used in `publish-release`) in the `build-release` job too, and pass it to `actions/checkout`. Since checkout stores the token as an HTTP `extraheader` in `.git/config`, all subsequent `git push` calls in that job use the App token instead of `GITHUB_TOKEN`. The tag push step runs immediately after checkout (~30s window), well within the App token's 1-hour expiry. ## Notes - Same fix needs to be cherry-picked to `release/3.4` and `release/3.3` - Releases from non-workflow commits are unaffected (latent bug that only surfaces when workflow files are part of the release HEAD commit)
lystopad
added a commit
that referenced
this pull request
Mar 25, 2026
…h with workflows scope (#20157) ## Summary When a release is triggered from a commit that touches `.github/workflows/` files, GitHub requires the `workflows` scope to push the git tag. `GITHUB_TOKEN` does not have this scope, causing the tag push to fail: > `! [remote rejected] v3.3.10 -> v3.3.10 (Unable to determine if workflow can be created or updated due to timeout; workflows scope may be required.)` Real-world failure: https://github.com/erigontech/erigon/actions/runs/23549095701/job/68557718510 ## Fix Generate the GitHub App token (already used in `publish-release`) in the `build-release` job too, and pass it to `actions/checkout`. Since checkout stores the token as an HTTP `extraheader` in `.git/config`, all subsequent `git push` calls in that job use the App token instead of `GITHUB_TOKEN`. The tag push step runs immediately after checkout (~30s window), well within the App token's 1-hour expiry. ## Notes - Same fix needs to be cherry-picked to `release/3.4` and `release/3.3` - Releases from non-workflow commits are unaffected (latent bug that only surfaces when workflow files are part of the release HEAD commit)
yperbasis
pushed a commit
that referenced
this pull request
Mar 26, 2026
…lback (#20164) Cherry-pick of #20157 and #20162 to `release/3.3`. ## Summary - `build-release`: use GitHub App token for checkout so `git push` of the release tag has `workflows` scope (#20157) - `In-case-of-failure`: same App token treatment for the rollback `git push -d` that deletes the tag on failure (#20162) Both fixes require `RELEASE_BOT` App to have `Workflows: Write` permission (already granted). Co-Authored-By: Claude
yperbasis
pushed a commit
that referenced
this pull request
Mar 26, 2026
…lback (#20165) Cherry-pick of #20157 and #20162 to `release/3.4`. ## Summary - `build-release`: use GitHub App token for checkout so `git push` of the release tag has `workflows` scope (#20157) - `In-case-of-failure`: same App token treatment for the rollback `git push -d` that deletes the tag on failure (#20162) Both fixes require `RELEASE_BOT` App to have `Workflows: Write` permission (already granted). Co-Authored-By: Claude
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
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
When a release is triggered from a commit that touches
.github/workflows/files, GitHub requires theworkflowsscope to push the git tag.GITHUB_TOKENdoes not have this scope, causing the tag push to fail:Real-world failure: https://github.com/erigontech/erigon/actions/runs/23549095701/job/68557718510
Fix
Generate the GitHub App token (already used in
publish-release) in thebuild-releasejob too, and pass it toactions/checkout. Since checkout stores the token as an HTTPextraheaderin.git/config, all subsequentgit pushcalls in that job use the App token instead ofGITHUB_TOKEN.The tag push step runs immediately after checkout (~30s window), well within the App token's 1-hour expiry.
Notes
release/3.4andrelease/3.3