ci(release): degrade the back-merge instead of failing a shipped release - #636
Open
0x-copilot-dev wants to merge 2 commits into
Open
0x-copilot-dev wants to merge 2 commits into
0x-copilot-dev wants to merge 2 commits into
Conversation
`release-cli`'s last step pushes `dev` directly, and dev's ruleset rejects it:
GH013: Repository rule violations found for refs/heads/dev.
- Changes must be made through a pull request.
- 4 of 4 required status checks are expected.
`GITHUB_TOKEN` is not a bypass actor, and because this repository is owned by a
USER rather than an org, `actor_type: Integration` bypass entries cannot be
granted at all (root CLAUDE.md #6) -- so there is no permission to add that
would make the push work. It has failed on every release, not just the last one.
That produced the worst outcome available at that point in the job. The publish
is irreversible several steps earlier, so the red run described a release that
had in fact shipped (0.3.0 was live on npm, tagged, and released), and the
obvious response -- re-run it -- dies on "already published" without repairing
the drift it was named for. Meanwhile main sits one commit ahead of dev, which
is exactly what `promote-to-main` refuses to promote over, so the NEXT release
is blocked by the previous one's cleanup.
The step now degrades rather than fails:
* pushes directly when `REPO_ADMIN_TOKEN` is configured (a PAT for an account
that IS a bypass actor makes this fully automatic; unset today),
* otherwise parks the merged state on `release/back-merge-<version>` and opens
a PR into dev -- rulesets cover only refs/heads/{dev,main}, so that push is
allowed -- turning the repair into one click instead of a git incantation
someone has to remember at the end of a release,
* writes which of those happened to the job summary, and warns loudly when
dev did not get the commit,
* never fails the release. `continue-on-error` is the backstop for the
unexpected paths; the script itself handles the expected ones and exits 0.
A conflict is still reported and never forced, as before.
Verified by running the extracted script against stubbed `git`/`gh` over all six
paths -- conflict, push-ok, push-ok-with-token, rejected-then-PR, rejected-then-
gh-fails, rejected-then-side-push-fails. Every one exits 0 with the right
annotation and summary line.
Per CLAUDE.md #3 no `${{ }}` is interpolated into the script; the token, repo
and version arrive through `env:`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GitHub does not start workflow runs for events raised by GITHUB_TOKEN, so the four required checks on the back-merge PR never report -- not pending-then-green, never. Merging it therefore needs `--admin` for two independent reasons, and a PR wedged on checks that will never run is a confusing thing to find at the end of a release. Say so in the body the workflow writes, and in the step comment. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
release-cli's final step, Back-merge the release commit into dev, fails on every release. Seen most recently on run 32044497852 publishing@0x-copilot/cli0.3.0:Why it cannot just be fixed with a permission
GITHUB_TOKENis not a ruleset bypass actor, and this repository is owned by a user, not an org — soactor_type: Integrationbypass entries cannot be granted at all (root CLAUDE.md #6). There is no permission to add that makes the direct push work.Why the failure was worse than it looked
The publish is irreversible several steps earlier. So the red run described a release that had shipped — 0.3.0 was live on npm, tagged, and released — and the obvious response, re-running it, dies on "already published" without repairing the drift it was named for.
Meanwhile
mainsits one commit ahead ofdev, which is exactly whatpromote-to-mainrefuses to promote over. The previous release's uncleaned drift blocks the next one.The change
The step now degrades rather than fails:
REPO_ADMIN_TOKENis configured — a fine-grained PAT for an account that is a bypass actor (0x-copilot-dev) makes this fully automatic. Unset today, so the fallback is what runs.release/back-merge-<version>and opens it intodev. Rulesets cover onlyrefs/heads/{dev,main}, so that side-branch push is allowed. The repair becomes one click instead of a git incantation someone has to remember at the end of a release.devdid not get the commit, including the exact manual fast-forward.continue-on-erroris the backstop for unexpected paths; the script handles the expected ones and exits 0.A conflict is still reported and never forced, as before. Per CLAUDE.md #3 no
${{ }}is interpolated into the script — token, repo and version arrive throughenv:.Verification
The script was extracted and run against stubbed
git/ghacross all six paths:ghfailsPath 4 is what runs today. Takes effect on the next release; nothing changes until then.
🤖 Generated with Claude Code