fix(ci): pin gh release commands to fork via GH_REPO - #9
Merged
Conversation
Since the job adds a git remote named 'upstream' (blockscout/frontend), gh CLI resolves it as the default repo and 'gh release create/delete' target the upstream repo, failing with HTTP 403. Releases have been silently missing since v2.8.1. Set GH_REPO to pin gh to the fork. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
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.
Problem
The "Create release" step fails with:
gh release create/deleteruns without an explicit repo. The job adds a git remote namedupstream(blockscout/frontend) and gh CLI prefers the remote namedupstreamwhen resolving its default repo, so the commands target the upstream repo instead of the fork and fail with 403. The error URL in the logs is direct evidence.History (corrected during review): the bug has been latent since the workflow's first commit (bbf85a2, 2026-02-20). The clean-merge happy path first reached "Create release" on 2026-06-22 (v2.8.1, run 27986584388) and has failed with the same 403 ever since (v2.9.2 run 29318879341, v2.9.3 run 29507390797). The existing releases (v2.7.3, v2.8.0-alpha.2, v2.8.0) were all created manually (author: JOY), not by this workflow - it has never successfully created a release.
Only the release step is affected - merge, push, tags, and Docker build all succeed.
Fix
Set
GH_REPO: ${{ github.repository }}on the step. Verified: GH_REPO fully overrides remote-based resolution forgh releasecommands, and the "Create PR on conflict" step is immune (uses explicitrepos/${GITHUB_REPOSITORY}/...paths).Follow-up (after merge)
Backfill missing releases: v2.8.1, v2.9.1, v2.9.2, v2.9.3 (latest).
🤖 Generated with Claude Code