ci(deploy-neep): fetch fork PR heads via refs/pull/<N>/head#3953
Conversation
The previous checkout assumed the PR branch existed on `origin` and did `git reset --hard origin/$BRANCH`, which fails for PRs from forks. The deploy aborted with `fatal: ambiguous argument 'origin/<branch>'` — see #3945 (deploy comment). When a PR is detected, fetch the special `refs/pull/<N>/head` ref that GitHub maintains for every PR (same-repo or fork) and reset to it. Fall back to the original origin-branch path for `workflow_dispatch` (no PR context).
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe Neep deployment workflow's remote SSH script is updated to support checking out pull request heads when deployment is triggered by issue comments. It conditionally fetches ChangesPR-Aware Deployment Checkout
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
|



Description
Follow-up to #3951 and #3952. The deploy on #3945 (comment) failed at
[1/7] Checking out branchbecause the PR's head branchAdd-linux-release-arm-CMake-presetonly exists in the contributor's fork:The script ran
git fetch origin(upstreamopentibiabr/canary) followed bygit reset --hard origin/$BRANCH, which can't resolve a fork's branch.GitHub maintains a
refs/pull/<N>/headref on the upstream repo for every PR — same-repo or fork — so we can fetch and reset against that ref instead.Behaviour
Actual
/deployon a PR opened from a fork aborts at the checkout step.Expected
/deployworks for both same-repo and fork PRs.Type of change
What changed
HAS_PRandPR_NUMBERplumbed into the remote script fromsteps.setup.outputs.HAS_PR=trueandPR_NUMBERset):git fetch origin "+refs/pull/${PR_NUMBER}/head:refs/remotes/pr/${PR_NUMBER}", thengit checkout -B "$BRANCH" "refs/remotes/pr/${PR_NUMBER}", thengit reset --hard "refs/remotes/pr/${PR_NUMBER}". Works for fork PRs and same-repo PRs alike.workflow_dispatchon a known branch): unchanged —git checkout "$BRANCH" || git checkout -b "$BRANCH"thengit reset --hard "origin/$BRANCH".$BRANCHname is still used as the local branch name on the VPS and in the MOTD.Security note: the existing
author_associationgate (OWNER/MEMBER/COLLABORATORonly) still applies, so only trusted maintainers can trigger a fork-code deploy via/deploy.How Has This Been Tested
/deployon a same-repo PR — verify checkout still works through the new PR-ref path./deployon a fork PR — verify the deploy proceeds past the checkout step (the original symptom).workflow_dispatchon a non-PR branch — verify the fallback path still works.Test Configuration:
Checklist
Notes for reviewers
A separate, cosmetic issue is still visible in the same comment: every block of output is duplicated (e.g. the
=== [1/7] ...block, and even drone-ssh's own✅ Successfully executed commands to all hosts.banner). The drone-ssh banner is emitted locally byappleboy/ssh-action, not by our remote script — its appearance inoutputs.stdoutconfirms the duplication is in the action'scapture_stdoutmechanism rather than in our log file. Worth addressing as a follow-up; not in scope here.Summary by CodeRabbit