Repository navigation
chore: release through a PR because main is protected - #363
Merged
Merged
Conversation
main only accepts changes through PRs, so semantic-release can no longer push the release commit. Open a release PR with the version and changelog, and create the tag and GitHub release after it merges.
Opening the PR from Actions needs a repo setting that also lets workflows approve PRs. Push the branch and link the PR instead, so CI also runs on it. Limit token permissions, install from the lockfile only, and keep the token out of the push command.
Only publish when the merge came from the release branch with one commit, and nothing else merged while it was open. Otherwise other changes would ship without changelog entries.
Retry the PR lookup, since GitHub may not link a new commit to its PR right away. Skip creating the release when it already exists, so a re-run can still move the major tag.
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 after #362 failed with
GH006: Protected branch update failed, becausemainonly accepts changes through a PR.@semantic-release/gitpushes the release commit straight tomain. Nothing was published: there's no 9.0.1 tag or release, andv9didn't move.How
Release in two steps, with no new dependencies:
releaserunssemantic-release --dry-run. A small inline plugin in.releaserc.jssaves the next version and notes. The job bumpspackage.json, adds the notes toCHANGELOG.mdand pushesrelease/x.y.z. The job summary has a link that opens achore: create new release x.y.zPR with the title filled in.publishjob checks the merge before it releases anything. The merged PR must come fromrelease/<version>, have exactly one commit, and be based on the commit right before the merge. The last check keeps PRs that merged while the release PR was open from shipping without changelog entries. Then the job creates thex.y.ztag and GitHub release from the newestCHANGELOG.mdsection, and movesv<major>. If a check fails, revert the release PR and run the workflow again.A person opens the release PR, not the workflow. So Actions doesn't need the "Allow GitHub Actions to create and approve pull requests" setting, which would also let workflows approve PRs. And
reviewandtestrun on the release PR.Dependency code runs with a write token in
dryrunandrelease-pr, so this also tightens those jobs:permissions: {}, and each job asks only forcontents: write. semantic-release checks push access even in dry-run mode, sodryrunneeds it too.bun install --frozen-lockfile, so only the locked versions install.gh auth setup-gitbefore the push, so the token isn't in the command line or.git/config.@semantic-release/changelog,@semantic-release/execand@semantic-release/gitaren't used anymore, so I removed them. The lockfile change only moves existing packages around. It adds no new versions.Things to know:
@semantic-release/githubno longer posts "released in" comments or labels on issues and PRs.Test Plan
release-prsteps in a fresh clone ofmain, up to the push. The dry run found 9.0.1,npm pkg setchanged only the version line inpackage.json, and the notes landed at the top ofCHANGELOG.md.GH_TOKENset,gh auth setup-gitletgit push --dry-runreach the repo.compare/main...release/9.0.1?expand=1&title=chore%3A%20create%20new%20release%209.0.1.bun install --frozen-lockfilepasses with the updated lockfile.awkcommand inpublishpulls out only the 9.0.1 section.publishchecks against real merges. The squash merge of fix: support eas-cli 22 build json fields #360 fails with "The PR is not from release/9.0.1". With the branch and commit count checks stubbed, the merges of fix: support eas-cli 22 build json fields #360, [fingerprint] fix db saving #337, update packages #334, chore: update readme to better clarify production continuous deployment caveats #328, fix: one more merge confict fix #327, fix: fingerprint hash parsing #326 and feat(continuous-deploy-fingerprint): Add optional environment input for EAS updates #325 pass the base check, and a stubbed different merge parent fails with "main changed after the release branch was created".eab7a230, which has no PR.publishskipsgh release createwhen the release already exists, so a re-run can still movev<major>.gh release viewfinds 9.0.0 and doesn't find 9.9.9.chore: create new release 9.0.1and... 9.0.1 (#363), and rejects 9.0.2, 9.0.10 and 9.0.1x.actionlintpasses (shellcheck wasn't installed, so scripts weren't shellchecked).release, open and merge the release PR, and check that 9.0.1 is published andv9moves to it.🤖 Generated with Claude Code