feat: auto-close promoted channel release PRs#115
Merged
Conversation
When a cycle promotes (channel → main) or graduates (channel → channel), an open release PR on the source channel offers another prerelease of a cycle that already moved on. Close it with an explanatory comment when the destination's version/release PR is created; a fresh one is created if new work lands on the channel.
|
The changes in this PR will be included in the next version bump.
|
Promoted bump files stay pending on the destination branch until its version/release PR merges. Closing on every push in that window would kill the release PR of a newly restarted cycle (close → recreate ping-pong). Gate the close on the triggering push's before..after range actually adding files under .bumpy/<channel>/ — the same detection the channel publish trigger uses. Runs from the destination branch so the non-CI fallback (HEAD^..HEAD) diffs the triggering commit.
theoephraim
added a commit
that referenced
this pull request
Jun 13, 2026
…ior (#116) Doc gaps surfaced while dogfooding the `next` channel to completion. Docs-only; no bump file (nothing under `packages/` changes). **Release workflow examples (`github-actions.md`)** — both the split-jobs and single-job examples now: - comment that prerelease channel branches go in the `push` trigger too (`[main, next, beta]`), with a link to the channels doc, and - use a **per-ref concurrency group** (`bumpy-release-${{ github.ref }}`). With a single shared group, a `next` prerelease publish queues behind — or, with `cancel-in-progress: true`, gets cancelled by — a `main` release, despite touching different dist-tags. This is the exact lesson from our own `release.yaml`. The standalone **Concurrency** section now explains the why, and notes the plain group is equivalent if you only release from `main`. **`prereleases.md` setup** — the "only trigger change" line now also flags that an _existing_ workflow on a single concurrency group should switch to per-ref (new workflows get it from the example). **`cli.md`** — documents what `ci check` posts on channel PRs (prerelease plan, `-<preid>.x`, dist-tag) and on **promotion PRs** (reads `.bumpy/<channel>/`, shows the consolidated stable plan, calls out that merging ends the cycle) — behavior that shipped in #111/#113 but wasn't in the command reference. Not included here: the auto-close-promoted-release-PR docs ride with #115; nothing here references that unmerged behavior.
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.
Dogfood finding from the first promotion: after merging #110, the channel release PR #112 lingered open, offering to publish another rc of a cycle that had already moved to its stable release (#114). I closed it manually; this makes bumpy do it.
When: as part of creating/updating the destination's version PR —
alpha→beta).What: for each promoted source channel, look up an open PR on its
versionPr.branchhead and close it with a comment explaining why, noting a fresh release PR appears if more work lands on the channel. Failures are warn-only — a lingering PR is annoying, not dangerous. The current channel's own PR is explicitly never touched.Targeting
main(rather thannext) deliberately: this path executes via the published bumpy in the release workflow, so shipping it in 1.14.0 activates it for the next cycle's promotion — andnextis due for its post-promotion reset anyway. The bump file will fold into #114.Docs updated in the promotion section. 297 tests pass.
Update — race fix (b13e94d): the first cut closed the source channel's release PR whenever its bump files were pending on the destination, but promoted files stay pending until the destination's version/release PR merges (potentially days). If a user started a fresh
nextcycle in that window, an unrelated merge tomainwould close its legitimate release PR — then the next push tonextrecreates it, and the cycle repeats (close → recreate ping-pong).Now the close is gated on the triggering push actually adding files under
.bumpy/<channel>/(itsbefore..afterrange — the same detection the channel publish trigger uses), so it fires exactly once, on the promotion/graduation merge itself. Moved both call sites to after the checkout-back so the non-CI fallback (HEAD^..HEAD) diffs the triggering commit from the right branch.Thanks to @theoephraim for spotting the restarted-cycle race.