Repository navigation
ci: publish a PR opened with preview from its label run only - #307
Merged
Merged
Conversation
A label set when a PR is opened fires a `labeled` run of its own. On a branch other than feat/fix, both that run and the `opened` run published the commit, so the second failed as a duplicate version. The `opened` run no longer publishes for the label; synchronize and reopened runs still do while the PR has it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018BeQzzyPntbJyPicYWDqo3
Drop "one publish per commit" (a reopen on a published commit publishes it again), keep each condition of the label clause on its own line, and say in § CI which run publishes a PR opened with `preview`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018BeQzzyPntbJyPicYWDqo3
|
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
Reviewed the Publish preview condition and the CI note that says which run publishes a pull request opened with preview.
- Preview gate — An
openedrun on a branch that does not start withfeatorfixno longer publishes when the pull request already haspreview. Thelabeledrun that addspreviewstill does, and latersynchronizeorreopenedruns still do while the label is present. Branches that start withfeatorfixstill publish from every non-label run, and a label run on those branches still does not. - Docs — The CI section now says that opening such a pull request with
previewpublishes from the label run, not theopenedrun.
grok-4.7 | 𝕏
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
A label set when a PR is opened fires a
labeledrun of its own, and since #306 that run has its own concurrency group. On a branch other thanfeat/*orfix/*, a PR opened withpreviewpublished the same commit from itsopenedrun and from itslabeled previewrun, and the second failed as a duplicate version. Now only the label run publishes it.if(ci: keep label bursts from hiding the required checks theme-toggle#30) without itsevent_nameguard, which dx doesn't need because a push has nohead_ref. It gives the same result as env's single!= 'opened'term (ci: give each label run its own concurrency group env#73) on every actiontypeslists.docs/development.md§ CI says which run publishes a PR opened withpreview. § Preview releases still holds as written.Evidence
Before:
openedwithpreviewonci/x→ yes, and itslabeled previewrun → yes. That is two publishes of one commit, and the second fails.After:
opened→ no,labeled preview→ yes.The
if, parsed fromci.ymlonmain(before) and on this branch (after), was evaluated with GitHub's expression engine (@actions/expressions0.3.61) over every combination of event, branch, the label alabeledrun adds, and the labels on the PR: 49 cases, 0 that differ from the rules below, and only the twoopened+previewrows on another branch change.ci/xpreview(±chore)previewci/xpreview(±chore)ci/xpreview(±chore)ci/xchorechoreci/xchore(±preview)feat/x,fix/xprevieworchorefeat/x,fix/xmainAll 49 cases
mainfeat/xfeat/xpreviewfeat/xchorefeat/xpreview,chorefix/xfix/xpreviewfix/xchorefix/xpreview,choreci/xci/xpreviewci/xchoreci/xpreview,chorefeat/xfeat/xpreviewfeat/xchorefeat/xpreview,chorefix/xfix/xpreviewfix/xchorefix/xpreview,choreci/xci/xpreviewci/xchoreci/xpreview,chorefeat/xfeat/xpreviewfeat/xchorefeat/xpreview,chorefix/xfix/xpreviewfix/xchorefix/xpreview,choreci/xci/xpreviewci/xchoreci/xpreview,chorepreviewfeat/xpreviewchorefeat/xchorepreviewfeat/xpreview,chorechorefeat/xpreview,chorepreviewfix/xpreviewchorefix/xchorepreviewfix/xpreview,chorechorefix/xpreview,chorepreviewci/xpreviewchoreci/xchorepreviewci/xpreview,chorechoreci/xpreview,chorePublish previewis skipped on this PR's own runs (aci/branch with nopreview), which shows that the foldedifparses. Nopreviewlabel was added and nofeat/fixbranch was pushed to check it, because both publish to npm.pnpm rr check,pnpm test.Merge Danger
Door: two-way
Blast Radius: CI
labeledrun. That happens withgh pr create --label(ci: give each label run its own concurrency group env#73), Dependabot (chore(deps): bump the security group across 9 directories with 4 updates env#71) and peter-evans/create-pull-request (chore: regenerate CLI docs #305). A PR converted from an issue gets nolabeledrun: withpreview, it would publish on its next push instead.main: reopening a PR whose head commit is already published, or removingpreviewand adding it back on the same commit, publishes that commit again, and the publish fails as a duplicate.🤖 Generated with Claude Code
https://claude.ai/code/session_018BeQzzyPntbJyPicYWDqo3