fix(ci): unbreak cherry-pick automation after actions/checkout v7 bump#16374
Conversation
actions/checkout v7.0.0 (actions/checkout#2454) refuses to check out fork PR code from pull_request_target workflows unless allow-unsafe-pr-checkout is set. On a merged fork PR the default checkout commit is the base branch tip, which equals pull_request.merge_commit_sha, so the guard fires even though only merged, reviewed code is being checked out. Since argoproj#16342 bumped checkout to v7, every cherry-pick of a fork PR has failed at checkout. Give checkout an explicit 'ref: main' so the guard's commit comparison no longer applies; the merge commit is still reachable and is cherry-picked by SHA. Also set GH_REPO on the failure comment step: it previously needed the (failed) checkout for repo context, so checkout failures were never reported on the PR. Co-Authored-By: Claude Fable 5 <[email protected]> Signed-off-by: Alan Clucas <[email protected]>
π WalkthroughWalkthroughThis change modifies a GitHub Actions workflow file to explicitly set the checkout ref to main, avoiding a checkout v7 fork-PR guard issue, and adds a GH_REPO environment variable to the failure-comment step so it functions independent of local git checkout state. ChangesWorkflow checkout and failure handling fix
Estimated code review effort: 1 (Trivial) | ~5 minutes π₯ Pre-merge checks | β 5β Passed checks (5 passed)
β¨ Finishing Touchesπ§ͺ Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
π§Ή Nitpick comments (1)
.github/workflows/cherry-pick-single.yml (1)
43-47: π Security & Privacy | π΅ Trivial | π€ Low valuezizmor artipacked warning is a false positive here.
Persisted credentials from checkout appear intentional β the later
git push origin "$CHERRY_PICK_BRANCH"step relies on them since no explicit token-based remote is configured. Settingpersist-credentials: falsewould break that push unless the remote URL is reconfigured with the token. This predates the current diff, so no action needed unless you want to harden it.π€ Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/cherry-pick-single.yml around lines 43 - 47, The warning about persisted credentials in the Checkout repository step is a false positive, and the later git push in the cherry-pick flow depends on those credentials; keep the actions/checkout configuration in place unless you also update the push logic. If you choose to harden it, adjust the cherry-pick workflow so the remote is explicitly reconfigured with the generated token before changing persist-credentials, and verify the CHERRY_PICK_BRANCH push still works.Source: Linters/SAST tools
π€ Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/cherry-pick-single.yml:
- Around line 43-47: The warning about persisted credentials in the Checkout
repository step is a false positive, and the later git push in the cherry-pick
flow depends on those credentials; keep the actions/checkout configuration in
place unless you also update the push logic. If you choose to harden it, adjust
the cherry-pick workflow so the remote is explicitly reconfigured with the
generated token before changing persist-credentials, and verify the
CHERRY_PICK_BRANCH push still works.
βΉοΈ Review info
βοΈ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: aaf29685-51aa-43a7-b0c4-9fd92df11af3
π Files selected for processing (1)
.github/workflows/cherry-pick-single.yml
Motivation
Since #16342 bumped actions/checkout to v7.0.0, every automated cherry-pick of a fork PR has failed at the checkout step, e.g. this run for #16357.
checkout v7 (actions/checkout#2454) refuses to check out fork PR code from
pull_request_targetworkflows unlessallow-unsafe-pr-checkout: trueis set. Its guard compares the resolved checkout commit againstpull_request.head.shaandpull_request.merge_commit_sha. On a just-merged fork PR the default checkout commit is the base branch tip, which is the merge commit SHA, so the guard fires even though only merged, reviewed code is being checked out. PRs from branches in argoproj are unaffected, which is why this wasn't caught by every cherry-pick.The failure was invisible on the original PRs because the
Comment on failurestep relied on the (failed) checkout for repo context and errored withnot a git repository.Modifications
ref: mainto checkout so the guard's commit comparison no longer applies. This keeps the fork-PR guard active rather than opting out withallow-unsafe-pr-checkout: true, and is semantically identical: main's tip contains the merge commit, and the script cherry-picks by SHA.GH_REPOon theComment on failurestep so failures are reported on the original PR even when checkout fails.Verification
Root cause confirmed by reading the failed run logs and the guard implementation in
src/unsafe-pr-checkout-helper.ts@ v7.0.0: with an explicitref, thecommitinput is empty, so none of the guard's three match conditions (head repo,refs/pull/*ref, PR SHA) apply.After merging, the missed cherry-picks (#16357, #16274, #15991, and #16223/#16302 for 3.7) can be re-triggered by removing and re-adding their
cherry-pick/*labels.AI
Diagnosed and authored with Claude Code (Claude Fable 5), directed and reviewed by me.
π€ Generated with Claude Code
Summary by CodeRabbit