fix: ci check misses channel-dir bump files on promotion PRs#111
Merged
Conversation
ci check read only root bump files, so a promotion PR (next → main) — whose pending work lives in .bumpy/next/ — reported 'no bump files found' and failed. Read channel dirs like every other channel-aware path, and render channel-dir files with their subdir path so the view-diff/edit links resolve.
|
This PR targets the
|
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.
Found via the promotion PR #110: its check failed and commented "Merging this PR will not cause a version bump" even though the cycle has two pending bump files.
Root cause:
ciCheckCommandcalledreadBumpFiles(rootDir)without thechannelsoption, so files in.bumpy/next/were never parsed. On a promotion PR those are exactly the pending files (the diff vs main lists them), so the diff-based filter matched nothing → "no bump files" comment + exit 1.Fix:
ci checkreads channel dirs like every other channel-aware path. This is safe for all PR shapes: feature PRs never have shipped channel files in their diff vs the PR base; promotion (channel → main) and graduation (channel → channel) PRs do, and there they genuinely are pending.next/feature.mdwith subdir-aware view-diff/edit links (previously they'd have linked to the nonexistent root path).Deliberately not changed: the local
bumpy checkandbumpy addcommands also read bump files without channels, but they always diff againstconfig.baseBranch— making them channel-aware without base-branch awareness would wrongly count shipped channel files as branch coverage on feature branches offnext. Separate issue.Tests: promotion-PR comment rendering + the channel-path/basename id contract that the diff filter relies on. 295 pass.
After this merges to next, re-triggering the check on #110 should produce the proper stable-promotion comment (
1.13.2 → 1.14.0).