Skip to content

ci: use GitHub App token for checkout in build-release to fix tag push with workflows scope#20157

Merged
lystopad merged 2 commits into
mainfrom
feature/lystopad/release-workflow-app-token-tag-push
Mar 25, 2026
Merged

ci: use GitHub App token for checkout in build-release to fix tag push with workflows scope#20157
lystopad merged 2 commits into
mainfrom
feature/lystopad/release-workflow-app-token-tag-push

Conversation

@lystopad

Copy link
Copy Markdown
Member

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)

…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.
@lystopad lystopad requested a review from yperbasis March 25, 2026 16:28
@lystopad lystopad self-assigned this Mar 25, 2026
@lystopad lystopad enabled auto-merge March 25, 2026 17:40
@lystopad lystopad added this pull request to the merge queue Mar 25, 2026
Merged via the queue into main with commit 5c5511c Mar 25, 2026
89 of 95 checks passed
@lystopad lystopad deleted the feature/lystopad/release-workflow-app-token-tag-push branch March 25, 2026 20:48
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants