Conversation
Deploy previewBundle size
Check out the code infra dashboard for more information about this PR. |
LukasTy
left a comment
LukasTy
left a comment
There was a problem hiding this comment.
Nice initiative.
Claude raised some concerns.
| contains(github.event.pull_request.labels.*.name, 'needs cherry-pick') && ( | ||
| github.event.action == 'closed' || | ||
| github.event.label.name == 'needs cherry-pick' || | ||
| (startsWith(github.event.label.name, 'v') && endsWith(github.event.label.name, '.x')) |
There was a problem hiding this comment.
Claude Opus 5.5 observation
Adding a v*.x label re-runs the cherry-pick for every target label on the PR, not only for the new label. detectTargetBranch.js reads all v*.x labels, and the open-PR check skips a branch only while its cherry-pick PR is still open.
Example: the PR has needs cherry-pick + v9.x. The v9.x cherry-pick PR gets a manual conflict fix and is merged. Later, someone adds v8.x. The new run cherry-picks onto v9.x again with -X theirs. The conflicting hunks resolve to the master version, so the result is not empty. A new v9.x PR opens and reverts the manual fix. If the v9.x cherry-pick PR was closed as unwanted, the run opens it again.
The shared workflow already has a single-branch mode. We can use it for version-label events:
with:
target_branch: ${{ github.event.action == 'labeled' && github.event.label.name != 'needs cherry-pick' && github.event.label.name || '' }}
pr_number: ${{ github.event.action == 'labeled' && github.event.label.name != 'needs cherry-pick' && format('{0}', github.event.pull_request.number) || '' }}The retry path (remove and re-add needs cherry-pick) still re-runs all branches. The PR body can say that a retry also runs again on branches that already succeeded.
| - 'v*.x' | ||
| - 'master' | ||
| types: ['closed'] | ||
| types: ['closed', 'labeled'] |
There was a problem hiding this comment.
Claude Opus 5.5 observation
If someone adds needs cherry-pick and v9.x in one label-picker action after merge, GitHub sends one labeled event per label. Each payload has the full label list, so both events pass this gate and start two runs.
Only one cherry-pick PR opens, because the concurrency group in the shared workflow runs the open step one at a time. But both detect jobs post "Cherry-pick PRs will be created targeting branches: v9.x" on the PR. If one action adds three labels, the newest queued job also cancels the pending job, and a cancelled run shows in the Actions tab.
I did not test this. A possible fix is in mui-public: post the comment from the open job after gh pr create, and include the new PR URL. The second run then stops at the existing-PR check and posts nothing.
This branch has not been deployed
2 participants
The cherry-pick workflow only runs when a PR is closed, and it reads the labels from that event. If
needs cherry-pickor the target branch label is added after merge, nothing happens and there is no way to retrigger it.This also runs the workflow when a label is added to a merged PR that has
needs cherry-pick, as long as the added label isneeds cherry-pickitself or av*.xtarget label. The labels can be added in either order. To retry a failed cherry-pick, remove and re-addneeds cherry-pick. Merged PRs withoutneeds cherry-pickno longer start a run that the shared workflow skips anyway.The shared workflow in mui-public already handles this: it reads the merge commit and PR details from the API instead of the event, and skips when a cherry-pick PR for that branch is already open, so re-adding a label never creates a duplicate.