Repository navigation
chore: release with the built-in GitHub token - #362
Merged
Merged
Conversation
The expo-bot token lost write access to this repo, so releases fail with EGITNOPERMISSION. The built-in token already has the access the release needs.
Keep the token out of .git/config in publish, push only the major tag, and stop installing packages from npm in the tags job.
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.
Why
The release workflow fails with
EGITNOPERMISSION. TheEXPOBOT_GITHUB_TOKENsecret belongs toexpo-bot, which now has only read access to this repo. GitHub returnsPermission to expo/expo-github-action.git denied to expo-bot, and creating labels fails with 403 too.How
Use the built-in
github.tokenin thepublishandtagsjobs instead of the bot token. Each job asks only for what it needs.contents: writepushes the release commit and tags.issues: writeandpull-requests: writecover the labels and "released in" comments from@semantic-release/github.The rules on
mainonly block deletion and force pushes, so a normal push of the release commit works.The tradeoff is that pushes made with
github.tokendon't start other workflows.reviewandtestwon't run on thechore: create new releasecommit. That commit only changespackage.json,CHANGELOG.mdandbuild/.Some small hardening for the jobs that hold a write token:
publishchecks out withpersist-credentials: false, so the token isn't saved in.git/configwhere installed packages could read it. semantic-release adds the token to the push URL itself.tagspushes onlyv<major>.git push --force --tagswould overwrite any remote tag that differs from the local one.tagsreads the major version withnode -pinstead ofbun add --dev semverandactions/github-script. The job no longer runs the runner setup or installs packages from npm at release time.Test Plan
dryrunjob onmainalready usesgithub.token. Its log showsContents: write,Issues: writeandPullRequests: write, and semantic-release loggedAllowed to push to the Git repository.semantic-release --dry-runin a fresh clone with no saved git credentials, onlyGITHUB_TOKEN. It loggedAllowed to push to the Git repositoryand next version 9.0.1.v9alone. It touched onlyv9.releaseand check that 9.0.1 is published andv9moves to it.🤖 Generated with Claude Code