ci: sign the release branch with the bot GPG key#271
Merged
Conversation
Co-Authored-By: Claude Fable 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
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.
Summary
Mirrors the release-branch signing setup to the
v2.xline, in its final form after the three rounds it took on master (#267 → #268 → #269): without it,release: 2.0.3(#260) is unmergeable against the required-signatures ruleset, exactly like #245 was.release-please--branches--**trigger asign-release-branchjob: when the head commit is unsigned (release-please commits via the REST API, which cannot sign; the Update branch (rebase) button also rewrites the commit unsigned), it amends the commit with silverhand-bot's GPG key (BOT_GPG_KEY/BOT_GPG_PASSPHRASEorg secrets, same setup as logto-io/js) and force-pushes.fetch-depth: 0(a shallow amend orphans the commit — the ci: re-sign the release branch on every push #268 incident that auto-closed release: 3.0.0-beta #245), the refuse-to-push-an-orphan guard, the skip-when-already-signed guard (no self-retriggering), and an explicit push refspec.release-pleasejob is gated tov2.xpushes;target-branch: v2.xand theunmark-latestjob are untouched.Note: #260's branch predates this workflow, so its pushes won't trigger the job until the branch tree contains it — the first Update branch (rebase) on #260 after this merges brings the workflow in and the rebased commit gets signed automatically (the same live acceptance test as #270 on master). No rush either way: per the release ordering, #260 waits for 3.0.0 GA.
End-to-end precedent: on master this exact setup auto-signed the recreated release PR #270 (
d6233ea, Verified, parent intact) with no human intervention.Testing
target-branch,unmark-latest) untouched; the new job is additive.Checklist
.changeset(N/A — release-please)🤖 Generated with Claude Code