ci: land release bumps through a PR instead of pushing to master - #19
Merged
Conversation
master is about to require status checks, and a commit that was just created has none, so the release workflow can no longer push the version bump straight to master. That's the failure magic-modal is stuck on, and `github-actions[bot]` can't be given a ruleset bypass on a user-owned repo: the API only accepts the admin repository role, which the bot doesn't have. release-it now runs with `git.push: false`. It commits and tags locally, publishes to npm, and the workflow pushes the branch to `chore/release-vX.Y.Z`, opens a PR and turns on auto-merge. Tags live outside `refs/heads/*` so the ruleset doesn't cover them, and a hook pushes the annotated tag before the GitHub release is created. Merge commit, not squash. The tag points at the bump commit, and a squash rewrites it, which would leave the tag outside master's history and break `git describe` for the next release's changelog range. Moved the config to `.release-it.cjs` because it now needs a `commitFilter` function to keep `chore(release)` commits, both the bump and the merge, out of later changelogs.
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.
Release bumps now reach master through an auto-merging PR instead of a direct push, so required status checks can go on master without bricking releases.
Push restrictions
Rulesets apply to pushes as well as PR merges, and a commit created seconds ago has no checks against it, so
release.ymlpushing the version bump would fail atgit push. magic-modal is already stuck there and works around it withgit.push: falseand master left out of sync.A bypass for
github-actions[bot]only exists on org-owned repos. On a user-owned one the API answers "Actor GitHub Actions integration must be part of the ruleset source or owner organization" and accepts nothing but the admin repository role, which the bot doesn't hold.Release flow
release-it runs with
git.push: false. It bumps, writes the changelog, commits and tags locally, then publishes to npm. The workflow pushes that commit tochore/release-vX.Y.Z, opens a PR and enables auto-merge. A release stays oneworkflow_dispatch.Tags live in
refs/tags/*and a ruleset targeting the default branch coversrefs/heads/master, so the annotated tag still goes straight to the remote.Hook placement
The tag has to reach the remote before the GitHub release is created, or GitHub invents a lightweight tag at master's head and the release points at the wrong commit with no changelog in it.
after:git:releasenever fires under this config:Git.release()returns the result of its push step, release-it skipsafter:hooks on a falsy return, andpush: falsemakes that return false every time. The hook sits onbefore:github:release, which runs unconditionally.Merge strategy
Auto-merge uses a merge commit. The tag points at the bump commit, and a squash rewrites it into a new SHA, dropping the tag out of master's history.
git describe --tagscan't find it after that, and the next release computes its changelog from the wrong boundary.Config location
The config moved from
package.jsonto.release-it.cjs, since acommitFilterfunction is now needed to keepchore(release)commits out of later changelogs. Every release leaves two of them, the bump and the merge commit.Verified with
--dry-runon this branch: 1.0.9 to 1.0.10,git push origin refs/tags/v1.0.10sitting between the tag andrepos.createRelease, and nothing actually pushed, because release-it treats hooks as writes and skips them in a dry run.Proof
Required status checks are active on master (
Lint, test and buildandAnalyze (javascript), admin-role bypass only), and v1.0.11 went out with them on. npm, master, the tag and the changelog all agree, and the tag is an ancestor of master sogit describestill resolves it:The release run itself, including the step that opens the bump PR:
And the PR it opened, auto-merged as a merge commit after three checks passed:
Two rough edges showed up on the way, both fixed in follow-ups. v1.0.10 published and tagged and then failed to open its PR, because "Allow GitHub Actions to create and approve pull requests" was off; #20 landed it by hand and #21 turned the error into instructions. v1.0.11's checks were held as
action_requiredand needed approving before auto-merge fired; #23 documents that and the fork-PR approval policy is loosened.