Use pull_request_target so cherry-pick workflow runs from main - #159
Merged
Conversation
For pull_request events, GitHub loads the workflow definition from the PR head ref. PRs branched off main before the pre-merge cherry-pick workflow landed still carry the OLD workflow (which only triggered on pull_request closed and issues labeled), so labeling those PRs with patch does nothing — the new label trigger only exists on main. Switch to pull_request_target: the workflow is loaded from the base ref (main) regardless of what's on the PR head. Token has write scope under pull_request_target, but this workflow already checks out main (ref: main) and only runs git against PR commits — no npm install or PR-controlled scripts are executed, so the usual pull_request_target risk doesn't apply here. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
Reviewed; no blockers found. |
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.
Summary
Follow-up to #157. Labeling #154 with
patchproduced no workflow run.Root cause: for
pull_requestevents, GitHub loads the workflow definition from the PR head ref, not from main. PR #154's branch (fix/replication-protocol-close-retry) was created before the pre-merge cherry-pick workflow landed, so it carries the OLDcherry-pick-patch.ymlthat only triggers onpull_request closedandissues labeled. The newpull_request labeledtrigger only exists on main, so the label change on #154 was silently ignored.Fix
Switch the trigger from
pull_requesttopull_request_target. Withpull_request_target, GitHub loads the workflow definition from the base ref (main) regardless of what's on the PR head, so any open PR — even those branched before the new flow landed — picks up the current workflow.Security note
pull_request_targetruns with a write-scope token against the base ref, which is normally dangerous because it can execute PR-controlled code. This workflow is safe because:actions/checkoutis pinned toref: main(from Pin cherry-pick workflow checkout to main #157), so the PR's tree is never the source of any executed code.git fetch/git cherry-picktouch PR commits — nonpm install, no PR-controlled scripts run inside this workflow.integration-tests.yaml) run separately, on the cherry-pick branch, with their own token scope.I'd appreciate a once-over on the security reasoning before merging.
After merge
For PR #154 specifically: unlabel and re-label
patchto fire the workflow against the updated trigger.🤖 Generated by Claude Opus 4.7 (1M context).