Stop checking out the fork PR head in claude-code-review.yml - #53
Conversation
actions/checkout refuses to check out a fork PR's head under pull_request_target by default (a hard-coded safety refusal added in a patch-level actions/checkout@v4 release), so review never actually ran against a genuine fork-originated PR - only against same-repo/upstream-branch PRs, which don't hit this check. The fix is not to opt back in via allow-unsafe-pr-checkout: true: claude-code-action already fetches and reads the PR's real content itself, internally, via the base repo's own refs/pull/<n>/head, so there is no reason for this job to put the fork's files in the workspace at all. The checkout step now fetches the base ref only, matching claude-code-action's own documented recommended pattern. pull_request_target always runs the workflow file from the base branch, so this PR's own claude-review check will still run the OLD broken workflow and fail the same way - that's expected, not a sign the fix doesn't work. Verification happens on a subsequent PR, after this merges to master.
📝 WalkthroughWalkthroughThe workflow documentation now states that Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
🧪 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 |
|
@claude pls review |
|
Claude finished @jnasbyupgrade's task in 2m 7s —— View job Review of PR #53
Verdict: looks correct, sound security improvement, no blocking issues. What changed: Security reasoning holds up:
One thing I couldn't independently verify: the specific claim that Expected self-failure note: the PR body's explanation that this PR's own No changes requested. |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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.
Inline comments:
In @.github/workflows/claude-code-review.yml:
- Around line 91-94: Update the actions/checkout reference in the
pull_request_target workflow to a verified full-length commit SHA instead of the
mutable v4 tag, and retain the existing security comment while documenting the
pinned version if appropriate. Ensure future SHA updates can be managed by
Dependabot or Renovate.
- Around line 89-97: Update the workflow’s Claude action reference from the
mutable anthropics/claude-code-action@v1 tag to a known-good immutable commit
SHA, while preserving the existing action configuration and checkout behavior.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: c0047cf0-53ce-4f0b-9026-66c661e2a480
📒 Files selected for processing (1)
.github/workflows/claude-code-review.yml
77a527d
into
Postgres-Extensions:master
Dropped along with the fork-checkout override, but it's independently worth keeping: this job never pushes anything, so there's no reason to leave a push-capable credential in .git/config for the rest of the job. Matches Postgres-Extensions/pg_count_nulls#53's version of this same fix.
* ci: bump Actions pins, add track_progress, add claude-debug label toggle Combines three related CI-workflow improvements into one PR (touching only claude-code-review.yml and claude.yml): - Bump actions/checkout@v4 -> @v7 (current latest major) to clear the Node.js-20-deprecation warning it triggers on every run. Supersedes/ incorporates upstream PR #13 and fork branch ci/bump-actions-versions, which made the same v4->v7 bump to the same two lines. anthropics/claude-code-action@v1 is still current (a floating v1 tag exists at v1.0.185) so it is left as-is. - Add track_progress: true to the claude-code-action step in claude-code-review.yml so it posts a live, updating checklist comment as it works instead of staying silent until the whole run finishes -- which, combined with this workflow's cost gate, could leave a PR dark for the better part of an hour. Disabled specifically for labeled-triggered runs (see below): the action's own track_progress validation only accepts opened/synchronize/reopened/ready_for_review for pull_request(_target) events and throws for any other action. - Add a claude-debug PR-label toggle so a maintainer can skip the cost gate and turn on full transcript output (show_full_output) by just labeling the PR, without editing/pushing the workflow file. The label is queried live via `gh pr view` inside the step rather than read from the event payload, since GitHub's "Re-run jobs" replays the original stored payload and would miss a label added afterward. `labeled` is added to the trigger types so applying the label alone starts a fresh run, scoped tightly in the job's `if:` so an unrelated label can't re-trigger this paid workflow. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * CI: fix claude-review failing at checkout on every fork PR actions/checkout now refuses, by default, to check out a fork PR's head under pull_request_target (a "pwn request" guard) -- this job has always been safe to opt out of that guard (trusted-fork gate + read-only use), it just started failing when the guard shipped. * Fix checkout pattern: don't redirect origin to the fork allow-unsafe-pr-checkout: true plus a repository:/ref: override checking out the fork directly is the wrong fix -- it silences the checkout refusal but breaks claude-code-action's own internal fetch of refs/pull/<n>/head (which only exists on this repo, not the fork), per Postgres-Extensions/extension_tools#28 hitting and fixing the identical mistake. The action already fetches and reads the PR's actual content itself; this step only needs to check out the base branch. * CI: register inline-comment MCP tool for claude-code-review The review step drives claude-code-action with a bare prompt: (no @claude mention), which runs it in "agent mode". That mode decides which MCP servers to start from an --allowedTools flag inside claude_args, not from the invoked plugin's own allowed-tools frontmatter. Without mcp__github_inline_comment__create_inline_comment listed there, that MCP server never starts, so the code-review plugin silently falls back to one consolidated PR comment instead of real per-line inline comments. * Fold in #26: check PR author (user.login), not head repo owner head.repo.owner.login only identifies the fork for fork-headed PRs; for an upstream-branch-headed PR (base and head both in this repo) it's always this repo's own org, never the actual author, so the gate silently skipped review on every such PR regardless of who opened it. user.login is GitHub's own authenticated record of who opened the PR and isn't attacker-spoofable, so this isn't a weaker check -- it's the more correct one, and covers both fork-headed and upstream-headed PRs. * Restore persist-credentials: false on the base-ref checkout Dropped along with the fork-checkout override, but it's independently worth keeping: this job never pushes anything, so there's no reason to leave a push-capable credential in .git/config for the rest of the job. Matches Postgres-Extensions/pg_count_nulls#53's version of this same fix. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
actions/checkout refuses to check out a fork PR's head under pull_request_target by default (a hard-coded safety refusal added in a patch-level actions/checkout@v4 release), so review never actually ran against a genuine fork-originated PR — only against same-repo/upstream-branch PRs, which don't hit this check. The fix is not to opt back in via allow-unsafe-pr-checkout: true: claude-code-action already fetches and reads the PR's real content itself, internally, via the base repo's own refs/pull//head, so there's no reason for this job to put the fork's files in the workspace at all. The checkout step now fetches the base ref only, matching claude-code-action's own documented recommended pattern.
Note: pull_request_target always runs the workflow file from the base branch, so this PR's own claude-review check will still run the OLD broken workflow and fail the same way — that's expected, not a sign the fix doesn't work. Verification happens on a subsequent PR, after this merges to master.