cursor-review: skip fork PRs; degrade to job summary on read-only token#12
Conversation
…oken Fork PRs can't run this review: the pull_request event withholds secrets (CURSOR_API_KEY is empty, so every panel cell produces empty output) and grants a read-only GITHUB_TOKEN (posting the consolidated review returns HTTP 403 "Resource not accessible by integration"). The review can neither analyze nor post, yet it still ran the 8-cell matrix + judge and failed the check red on every external contribution (e.g. Comfy-Desktop#973). Two complementary fixes: 1. Gate: skip when head.repo.full_name != github.repository (the cross-repo signal). No wasted matrix, no red X — the check is simply skipped, the standard outcome for a workflow that needs secrets a fork PR can't have. 2. post-review.py: when a review POST fails with a read-only-token 403, render the review into the job step summary and exit 0 instead of failing. Defense-in-depth for same-repo runs that can still hit a read-only token (read-only default workflow permissions, token-downgrading events). Genuine non-permission failures (e.g. HTTP 422) still exit 1 — no silent swallow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe workflow adds an early-exit fork-PR guard in the ChangesFork detection and read-only token degradation
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
What
Two complementary fixes so cursor-review stops failing red on PRs it fundamentally can't review.
Why
A fork PR (Comfy-Desktop#973) failed the
cursor-reviewcheck. Tracing it:adversarial (gemini-3.1-pro)) actually passed — every panel cell did.Consolidate panel → Post review:Root cause: on a PR from a fork, the
pull_requestevent gives the workflow no secrets and a read-onlyGITHUB_TOKEN. So:CURSOR_API_KEYis empty →cursor-agenterrorsAuthentication requiredon all 8 cells → every cell produces empty output → judge skipped → "no findings".The review can neither analyze nor post on a fork PR, yet it still ran the full 8-cell matrix + judge and failed the check on every external contribution.
Changes
1. Gate — skip fork PRs (
cursor-review.yml)Skip when
head.repo.full_name != github.repository(the cross-repo signal, ==isCrossRepository). No wasted matrix, no red X — the check is simply skipped, the standard outcome for a workflow that needs secrets a fork PR can't have.2.
post-review.py— degrade to job summary on a read-only-token 403 (defense-in-depth)If a review POST fails with
Resource not accessible by integration/HTTP 403, render the review into the job step summary and exit 0 instead of failing. Covers same-repo runs that can still hit a read-only token (read-only default workflow permissions, token-downgrading events). Genuine non-permission failures (e.g. HTTP 422) still exit 1 — no silent swallow.Testing
python3 -m py_compile post-review.pyand YAML parse — both clean.post-review.pywith a fakegh:$GITHUB_STEP_SUMMARY, exit 0 ✓Not done (and why)
pull_request_targetwould grant a write token on fork PRs, but cursor-review checks out and runs an agent over untrusted PR code — handing that a privileged token is the textbook fork-PR footgun. The proper "review forks too" path is a separateworkflow_runjob that posts from base-repo context; out of scope here.🤖 Generated with Claude Code