ci: report Build & canary release once, and skip the canary on release PRs - #1264
Merged
Conversation
…e PRs Two leftovers in the release config, both surfaced now that the Version Packages PR actually runs the required workflows. `Build & canary release` was reported twice under the same context name: a three-second no-op in pull-request.yml and the real build in publish.yml. Branch protection could therefore be satisfied by whichever reported first, including the no-op that builds nothing. Remove the no-op; the real job in publish.yml carries the name. Both workflows share the same `paths-ignore`, so which PRs get the check is unchanged. The canary publish also ran on the Version Packages PR, whose diff is only a version bump and changelog — so it published a duplicate of what main had just released and left another stale `pr_*` dist-tag behind. Guard the publish and PR-comment steps on the release branch. The job still runs, so the required check reports and the build still verifies the exact tree about to ship. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: db03b3b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
📦 NPM canary releaseDeployed canary version 0.0.0-canary-a103318. |
Contributor
🧪 Storybook is successfully deployed!
|
Contributor
🏋️ Size limit report
Click here if you want to find out what is changed in this build |
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.
Describe changes
Two leftovers in the release config, both visible now that the Version Packages PR actually runs the required workflows (#1262).
1.
Build & canary releasewas reported twiceTwo jobs published the same check name:
pull-request.ymlbuild-canary-statusecho "Canary publishing is handled by publish.yml"— 3 seconds, builds nothingpublish.ymlpublish-canaryBoth appeared on every PR (visible on #1263), and since branch protection matches by name, the requirement could be satisfied by whichever reported first — including the no-op. Removed the no-op so the real job carries the name.
Both workflows share the same
paths-ignore(.changeset/**,.husky/**), so which PRs receive the check is unchanged by this.2. The canary published on the Version Packages PR
publish-canarywas gated only ongithub.event_name == 'pull_request', so the release PR got a canary too — despite its diff being nothing but a version bump and changelog. That published a duplicate of whatmainhad just released and left another stalepr_*dist-tag behind. Those tags accumulate:npm dist-tag ls @cube-dev/ui-kitcurrently listspr_69,pr_70,pr_72, … going back years.The publish and PR-comment steps are now guarded with
github.head_ref != 'changeset-release/main'.Deliberately guarding the steps, not the job. Skipping the whole job would stop
Build & canary releasefrom reporting, which would block the release PR — the exact problem #1262 just fixed. This way the job still runs, the required check still reports, andpnpm buildstill verifies the precise tree that is about to ship.Verification
This PR carries a changeset on purpose, so merging it exercises the full path end to end. What I'll check on the resulting Version Packages PR:
Build & canary releasecheck, not twopr_*dist-tag created for the release PRNot included
Pruning the existing stale
pr_*dist-tags is a separate cleanup — it mutates published npm metadata rather than CI config, so it doesn't belong in the same change.Checklist
patch, and intentionally so: it exercises the release flow this PR changesCloses: N/A
Other information
No runtime or published-code changes; the version bump exists to verify the pipeline.
🤖 Generated with Claude Code
Note
Low Risk
Workflow-only changes with no application code; the release PR still runs build and reports the required check.
Overview
CI-only release pipeline fixes so branch protection and npm tags behave correctly on normal and Version Packages PRs.
pull-request.ymldrops the no-opbuild-canary-statusjob that echoed a placeholder whilepublish.yml’spublish-canaryjob already reports the sameBuild & canary releasecheck name—so PRs get a single real check instead of two identically named ones.publish.ymladdsif: github.head_ref != 'changeset-release/main'on Publish canary to npm and Comment PR only. Thepublish-canaryjob still runs (build + check) on the changeset release branch; it just skips redundant npm publish and the canary comment that would duplicatemainand add another stalepr_*dist-tag.A patch changeset documents the maintenance release with no runtime code changes.
Reviewed by Cursor Bugbot for commit db03b3b. Bugbot is set up for automated code reviews on this repo. Configure here.