ci(changeset): skip validation on Changesets release PRs

[mattrothenberg]

Summary

The ci/scripts/validate-kumo-changeset.ts script enforces "if packages/kumo/ changed, a new .changeset/*.md file must exist." Correct rule for feature PRs — but guaranteed to fail on the Changesets release PR itself, because by construction the release PR:

• Modifies packages/kumo/package.json (version bump) and packages/kumo/CHANGELOG.md (entries).
• Deletes all .changeset/*.md files it consumed.
• Never adds new changesets.

Why this is only hitting us now

Prior "Version Packages" PRs didn't trigger the failure — but not because they were healthy. Bot-authored PRs require a maintainer to click "Approve and run" before the pull_request workflow actually executes. That approval was never granted on prior release PRs, so the Pull Request workflow sat in action_required forever and the validation never ran. PR #428 is the first release PR where the workflow was approved to run, exposing the latent false-positive.

Reference — same error on an earlier release PR when its workflow was briefly approved before a force-push:
https://github.com/cloudflare/kumo/actions/runs/24518655574/job/71669853648

The fix

Five lines in validate-kumo-changeset.ts: if the PR's head branch is changeset-release/* (the hardcoded naming convention from changesets/action), log and exit early. All other PRs — feature branches, Renovate/Dependabot bumps, human contributions — continue through full validation unchanged.

Alternatives considered

• Detect by PR author (github-actions[bot]) — fragile if the release token ever changes.
• Detect "deleted .changeset files but no new ones" — more semantic but more code, and you'd still want a branch check as a sanity gate anyway.
• Add a skip-changeset-validation label — requires a human action every release; self-healing > self-disciplining.
• Drop the CI validation entirely and rely on pre-push — pre-push can be bypassed with --no-verify; the CI check is the belt-and-suspenders layer and worth keeping.

Expected behavior after this lands

• Feature PR missing a changeset → still fails loudly (unchanged).
• Release PR (changeset-release/*) → logs Detected Changesets release PR (branch: changeset-release/main); skipping validation. and exits 0 → green check.

After merge, re-run the latest Release workflow to regenerate PR #428:

gh run rerun 24792409741

Red X on #428 should clear on the next workflow run.

Checklist

• Reviews
• bonk has reviewed the change
• automated review not possible because: single-file CI script change with well-scoped blast radius
• Tests
• Tests included/updated
• Automated tests not possible - manual testing has been completed as follows:
• Additional testing not necessary because: the change is a narrow early-exit in a CI validation script; behavior is directly observable on the next release PR workflow run, and the non-release-PR path is unchanged

[mattrothenberg]

/bonk

[ask-bonk]

Looking at the code changes in validate-kumo-changeset.ts, I can see the fix adds an early-exit check (lines 45-58) that detects Changesets release PRs by checking if the branch name starts with changeset-release/.

The implementation is clean and well-documented:

1. Correct detection mechanism - Uses GITHUB_HEAD_REF (PR branch name in CI) with a fallback to GITHUB_REF_NAME, checking for the changeset-release/ prefix that changesets/action uses
2. Early return before validation - Skips validation entirely for release PRs, preventing the false-positive failure
3. Good observability - Logs the detected branch name for transparency in CI logs
4. Minimal blast radius - Only affects release PRs; all other PRs continue through full validation unchanged

The logic is sound: release PRs by design modify packages/kumo/ (version bumps, CHANGELOG updates) while consuming (deleting) changeset files rather than adding new ones, so the validation rule "changes in packages/kumo/ must have a new changeset" would always fail for them.

LGTM 👍

One minor thought: Consider whether GITHUB_HEAD_REF alone is sufficient (vs the fallback to GITHUB_REF_NAME). For PR-triggered workflows, GITHUB_HEAD_REF will always be set. The fallback could potentially match a branch named changeset-release/something pushed directly (not via PR), but since this script is only invoked in PR contexts per the isPullRequestContext() check, this is a non-issue in practice.

github run

[mattrothenberg]

/bonk good catch. the GITHUB_REF_NAME fallback was dead code. In pull_request workflow context GITHUB_REF_NAME resolves to refs/pull//merge which would never match changeset-release/*, so the fallback was never a correctness backup — just noise. Dropped it in 358cd29 and added a comment making the isPullRequestContext() dependency explicit.

[ask-bonk]

The fix correctly identifies Changesets release PRs by checking for the 'changeset-release/' branch prefix, which is the reliable naming convention used by changesets/action.

Key points:

• Clean early-exit before validation logic (lines 45-61)
• Uses GITHUB_HEAD_REF which is always set in PR workflow contexts
• Good logging for CI observability
• Minimal, targeted change with no impact on regular PR validation

The logic is sound: release PRs consume (delete) changeset files rather than adding them, so the validation rule would always incorrectly fail for them. This fix ensures release PRs get a green check while maintaining strict validation for all other PRs.

[ask-bonk]

Posted an approving review on PR #436.

Summary of the review:

The fix correctly identifies Changesets release PRs by checking for the changeset-release/ branch prefix. The implementation is clean and well-scoped:

• ✅ Early-exit at lines 45-61 before validation logic runs
• ✅ Uses GITHUB_HEAD_REF which is always set in PR workflow contexts
• ✅ Good logging for CI observability
• ✅ Minimal blast radius — no impact on regular PR validation

The logic is sound: release PRs by design consume (delete) changeset files rather than adding them, so the "must add a new changeset" validation would always incorrectly fail. This fix ensures release PRs pass while maintaining strict validation for all other PRs.

github run

[pkg-pr-new]

npm i https://pkg.pr.new/@cloudflare/kumo@436

commit: 358cd29

[github-actions]

Docs Preview

View docs preview

Commit: 697e290