docs: update README and CI guide for v0.6.0 - #55
Conversation
README.md: - Opening line: add GitHub + OpenAI-compatible support - Features: 6 new v0.6.0 features (GitHub, suggestions, multi-line, description update, cleanup mode, draft notes) - Quick Start: add GitHub Actions section with full workflow example - Config tables: add --update-description, --cleanup-mode, GITHUB_TOKEN - Auth: add GitHub API token reference - Per-repo config: add update_description, cleanup_mode - Fix stale version refs (v0.5.1 → v0.6.0) docs/CI-SETUP.md: - Replace GitHub Actions workaround with native integration guide - Add GitHub Code Scanning (SARIF) section - Document GITHUB_TOKEN permissions
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThe documentation now presents GitHub pull request review alongside GitLab support, documents new review configuration options, updates GitHub Actions setup for v0.6.0, and adds SARIF workflow guidance with Code Scanning upload permissions. ChangesGitHub integration documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 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 |
![coderabbitai[bot]](https://avatars.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@README.md`:
- Around line 152-156: Update the README CLI options table entry for --ci to
describe its platform-neutral CI behavior, replacing the GitLab-specific wording
while leaving the workflow invocation and other option documentation unchanged.
- Around line 127-159: Document the fork pull-request limitation for the GitHub
workflows: in README.md lines 127-159 and docs/CI-SETUP.md lines 127-154 and
163-200, explain that fork-triggered pull_request workflows receive read-only
GITHUB_TOKEN permissions by default, so pull-requests: write and
security-events: write actions fail unless write tokens for forks are explicitly
enabled, and note the associated security risk or recommend a separately secured
trusted workflow.
- Around line 134-138: Add id-token: write to the permissions blocks for all
three GCP Workload Identity Federation workflows using
google-github-actions/auth: README.md lines 134-138, docs/CI-SETUP.md lines
134-145, and docs/CI-SETUP.md lines 170-182. Preserve each block’s existing
contents, including contents, pull-requests, and security-events permissions
where present.
🪄 Autofix (Beta)
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: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 48bb0e31-babe-4c11-8a7d-2e35323a9cd1
📒 Files selected for processing (2)
README.mddocs/CI-SETUP.md
| ```yaml | ||
| name: Code Review | ||
| on: | ||
| pull_request: | ||
| types: [opened, synchronize] | ||
|
|
||
| jobs: | ||
| review: | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: read | ||
| pull-requests: write | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 | ||
|
|
||
| - uses: google-github-actions/auth@v2 | ||
| with: | ||
| workload_identity_provider: ${{ secrets.WIF_PROVIDER }} | ||
| service_account: ${{ secrets.WIF_SA }} | ||
|
|
||
| - name: Install code-reviewer | ||
| run: go install github.com/OpticDiff/code-reviewer/cmd/code-reviewer@v0.6.0 | ||
|
|
||
| - name: Review PR | ||
| env: | ||
| GOOGLE_CLOUD_PROJECT: ${{ secrets.GCP_PROJECT }} | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} | ||
| run: code-reviewer --ci | ||
| ``` | ||
|
|
||
| The `GITHUB_TOKEN` is provided automatically by GitHub Actions. The tool detects the GitHub environment and posts review comments on the PR. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf 'Git status/stat:\n'
git diff --stat || true
printf '\nRelevant README/CI-SETUP excerpts:\n'
for f in README.md docs/CI-SETUP.md; do
if [ -f "$f" ]; then
echo "---- $f ----"
wc -l "$f"
sed -n '110,210p' "$f" | sed -n '1,70p'
else
echo "missing $f"
fi
done
printf '\nSearch for repository/CI setup guidance around forks/settings:\n'
rg -n "fork|Fork|read-only|permission|pull-requests: write|security-events: write|GITHUB_TOKEN" README.md docs/CI-SETUP.md .Repository: OpticDiff/code-reviewer
Length of output: 8498
🌐 Web query:
GitHub Actions pull_request forks write token permissions fork repository pull_requests read only
💡 Result:
When a GitHub Actions workflow is triggered by a pull request from a forked repository using the pull_request event, GitHub automatically adjusts the permissions of the GITHUB_TOKEN to read-only [1][2]. This restriction is a critical security measure to prevent unauthorized users from escalating privileges or accessing repository secrets [3][4]. Key details regarding this behavior include: 1. Automatic Downgrade: For workflows triggered by a pull request from a fork, any write permissions explicitly configured in the workflow file are downgraded to read-only [2][5]. This applies to pull_request, pull_request_review, and pull_request_review_comment events [2][5]. 2. Secret Access: Workflows triggered by pull_request from a fork do not have access to repository or organization secrets [1][3]. 3. Repository Settings: Maintainers can control these behaviors through the repository's Actions settings: - Send write tokens to workflows from pull requests: If enabled, this allows fork pull requests to use a GITHUB_TOKEN with write permissions [1]. This should be used with extreme caution [6]. - Require approval for fork pull request workflows: This policy can force workflows from non-collaborators to wait for approval from someone with write access before running [1]. 4. The pull_request_target Event: Unlike the standard pull_request event, pull_request_target runs in the context of the base repository and is granted access to secrets and a read/write GITHUB_TOKEN [3][4]. Because this event runs with elevated trust, it is a frequent target for exploitation (often called pwn requests) [7][6]. It is highly recommended never to check out, build, or run untrusted code from a fork when using this trigger [3][8][6]. Recent security updates (as of June 2026) have introduced stricter defaults for actions/checkout to prevent insecure checkouts of fork code in these workflows [7]. For secure automation, it is recommended to separate build and reporting tasks. Use a pull_request workflow (read-only, no secrets) to build and test code, and use a separate, restricted workflow triggered by other means (e.g., workflow_run) or with careful validation in pull_request_target to handle tasks requiring write access or secrets [4][8][6].
Citations:
- 1: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository
- 2: Clarify Permissions Calculation for Workflow Jobs in Documentation github/docs#33566
- 3: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 4: https://github.blog/news-insights/product-news/github-actions-improvements-for-fork-and-pull-request-workflows/
- 5: Clarify
How the permissions are calculated for a workflow jobgithub/docs#32398 - 6: https://asecurityengineer.com/posts/hardening-github-actions-workflows/
- 7: https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/
- 8: https://stackoverflow.com/questions/76952023/how-to-make-github-actions-safely-access-secrets-for-prs-created-from-forks
Document the fork PR token limitation in the GitHub workflows.
pull_request workflows from forks receive read-only GITHUB_TOKEN permissions by default, so the pull-requests: write and SARIF security-events: write workflows will fail unless the repository explicitly allows write tokens for forks—a security-sensitive setting. Address this at:
README.md#L127-L159docs/CI-SETUP.md#L127-L154docs/CI-SETUP.md#L163-L200
Consider documenting the fork limitation or moving trusted PR-writing tasks to a separately secured design/workflow instead.
📍 Affects 2 files
README.md#L127-L159(this comment)docs/CI-SETUP.md#L127-L154docs/CI-SETUP.md#L163-L200
🤖 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 `@README.md` around lines 127 - 159, Document the fork pull-request limitation
for the GitHub workflows: in README.md lines 127-159 and docs/CI-SETUP.md lines
127-154 and 163-200, explain that fork-triggered pull_request workflows receive
read-only GITHUB_TOKEN permissions by default, so pull-requests: write and
security-events: write actions fail unless write tokens for forks are explicitly
enabled, and note the associated security risk or recommend a separately secured
trusted workflow.
- Add id-token: write to all WIF permissions blocks (required for OIDC) - Update --ci flag description to platform-neutral wording
1 participant
Updates documentation to reflect all v0.6.0 features.
README.md
--update-description,--cleanup-mode,GITHUB_TOKENupdate_description,cleanup_modev0.5.1→v0.6.0)docs/CI-SETUP.md
GITHUB_TOKENpermissions (pull-requests: write)Summary by CodeRabbit