Add reusable workflow to trigger CodeRabbit review on bot PRs

[tpantelis]

CodeRabbit has implicit default behavior that automatically skips bot PRs. The recommended solution is to add a workflow that adds a PR comment to trigger review. This commit adds a reusable workflow that centralizes the logic and can be called from a small workflow in each repository.

Summary by CodeRabbit

• Chores
  • Added automated code review workflow to the CI/CD pipeline that automatically initiates CodeRabbit AI reviews for pull requests when triggered by designated bot accounts.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[submariner-bot]

🤖 Created branch: z_pr231/tpantelis/add-coderabbit-dependabot-workflow

[coderabbitai]

Warning

Rate limit exceeded

@tpantelis has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 12 minutes and 31 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 57a93eb and 887de52.

📒 Files selected for processing (1)

• .github/workflows/coderabbit-trigger.yml (1 hunks)

Walkthrough

A new GitHub Actions workflow file is introduced that automatically triggers CodeRabbit reviews on pull requests. The workflow is callable from other workflows, runs only for specific bot actors, and uses the GitHub API to check for and post review comments when absent.

Changes

Cohort / File(s)	Summary
New GitHub Actions Workflow \\.github/workflows/coderabbit-trigger.yml	Introduces a reusable workflow invoked via workflow_call with a pr_number input. Runs exclusively for dependabot[bot] and submariner-bot actors with issues: write permissions. Uses actions/github-script@v8 to fetch PR comments, check for existing "@coderabbitai review" comment, and conditionally post it if absent.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• Verify the actor restrictions (dependabot[bot] and submariner-bot) are the intended accounts
• Confirm the GitHub Script logic correctly detects existing comments and posts only when needed
• Check that the pr_number input is properly used and passed to the workflow caller

Pre-merge checks

Caution

Pre-merge checks failed

Please resolve all errors before merging. Addressing warnings is optional.

• Ignore

❌ Failed checks (1 error)

Check name	Status	Explanation	Resolution
Actionable Comments Resolved	❌ Error	The actionable comment specifying that secrets.GITHUB_TOKEN should be replaced with ${{ github.token }} has not been resolved.	Update line 18 in .github/workflows/coderabbit-trigger.yml to replace github-token: ${{secrets.GITHUB_TOKEN}} with github-token: ${{ github.token }}.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a reusable GitHub Actions workflow to trigger CodeRabbit reviews on bot PRs, which is exactly what the changeset implements.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/coderabbit-trigger.yml (1)

13-21: Avoid duplicate trigger comments (optional).
As-is, every rerun posts another @coderabbitai review comment. Consider checking existing comments first and only posting if absent.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ddcbec0 and f2af61e.

📒 Files selected for processing (1)

• .github/workflows/coderabbit-trigger.yml (1 hunks)

🔇 Additional comments (1)

.github/workflows/coderabbit-trigger.yml (1)

10-12: No change needed: pull-requests: write is sufficient for issues.createComment on pull requests.

GitHub treats pull requests as issues, so github.rest.issues.createComment works with either issues: write or pull-requests: write permissions. Since this workflow operates within a pull request context (context.issue.number), the current pull-requests: write permission is adequate and requires no modification.

Likely an incorrect or invalid review comment.

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f2af61e and b0aeb41.

📒 Files selected for processing (1)

• .github/workflows/coderabbit-trigger.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Go

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/coderabbit-trigger.yml (1)

3-8: Tighten trigger-comment detection to reduce false positives (optional).
Right now any comment containing @coderabbitai review (even a human quoting it) will suppress posting. Consider matching exact body (trimmed) and/or restricting to comments authored by github-actions[bot] to keep the workflow deterministic.

-            const commentExists = comments.some(c => (c.body ?? '').includes(triggerComment));
+            const commentExists = comments.some(c =>
+              (c.user?.login === 'github-actions[bot]') &&
+              ((c.body ?? '').trim() === triggerComment)
+            );

Also applies to: 19-38

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b0aeb41 and 5783a1d.

📒 Files selected for processing (1)

• .github/workflows/coderabbit-trigger.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Go

🔇 Additional comments (1)

.github/workflows/coderabbit-trigger.yml (1)

17-28: No action needed. github.paginate() is fully supported and documented in actions/github-script@v8. The pre-authenticated Octokit client includes pagination capabilities, and this usage pattern is correct.

Likely an incorrect or invalid review comment.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/coderabbit-trigger.yml (1)

4-15: Consider improving testability and making the “already triggered” check stricter.
Right now the bot-only gate (Line 13) means a manual run (e.g., via a human workflow_dispatch) won’t do anything, which can be confusing when validating. Also, includes(triggerComment) (Line 29) can match quoted text; consider checking trim() === triggerComment or using a unique marker comment body.

Also applies to: 24-41

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5783a1d and ea65b30.

📒 Files selected for processing (2)

• .github/workflows/coderabbit-trigger.yml (1 hunks)
• .github/workflows/test-coderabbit-trigger.yml (1 hunks)

🧰 Additional context used

🪛 actionlint (1.7.9)

.github/workflows/test-coderabbit-trigger.yml

13-13: reusable workflow call "./github/workflows/coderabbit-trigger.yml@add-coderabbit-dependabot-workflow" at "uses" is not following the format "owner/repo/path/to/workflow.yml@ref" nor "./path/to/workflow.yml". see https://docs.github.com/en/actions/learn-github-actions/reusing-workflows for more details

(workflow-call)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Go

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

.github/workflows/test-cr-trigger.yml (1)

4-6: If this is a test-only workflow, gate it to avoid spamming bot comments on every PR.
Consider switching to workflow_dispatch (or restricting with paths, branches, or an if: on actor/label) so routine PRs don’t trigger it.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ea65b30 and 3e82898.

📒 Files selected for processing (1)

• .github/workflows/test-cr-trigger.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: Go

[tpantelis]

@coderabbitai why do I get HttpError: Resource not accessible by integration when creating a pull request comment using actions/github-script?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Read the coderabbit-trigger.yml workflow file to check permissions
cat .github/workflows/coderabbit-trigger.yml

Length of output: 1344

---

🏁 Script executed:

#!/bin/bash
# Read the test workflow that calls the reusable workflow
cat .github/workflows/test-cr-trigger.yml

Length of output: 166

---

@tpantelis The issue is that when calling a reusable workflow, permissions must be explicitly set in the calling workflow. The permissions block in your reusable workflow alone is not sufficient—GitHub requires the caller to grant those permissions.

In your test-cr-trigger.yml, you have secrets: inherit but no permissions block. By default, jobs calling reusable workflows get minimal read-only permissions.

Solution

Add a permissions block to the calling workflow:

---
name: Test CodeRabbit

on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  test:
    uses: ./.github/workflows/coderabbit-trigger.yml
    with:
      pr_number: 230
    secrets: inherit

Alternatively, if you want the calling workflow to have the most flexibility, you can use:

permissions:
  pull-requests: write

This grants the necessary permission to create PR comments. The key point is that both the caller and the called workflow need appropriate permissions, or you can set them at the workflow level in the caller and they'll be inherited by the reusable workflow.

[tpantelis]

@coderabbitai I tried adding pull_request write permission to the calling workflow but I still get "HttpError: Resource not accessible by integration". I also changed it to issues write permission in both the calling and called workflows but I still get "HttpError: Resource not accessible by integration". What is wrong?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check the current state of both workflow files
echo "=== coderabbit-trigger.yml ==="
cat .github/workflows/coderabbit-trigger.yml

echo -e "\n=== test-cr-trigger.yml ==="
cat .github/workflows/test-cr-trigger.yml

# Check if there are any workflow settings or GitHub Actions configuration
echo -e "\n=== Checking for GitHub Actions configuration ==="
fd -t f 'settings.yml' .github/ --exec cat {}

# Check for any organization or repository level workflow permissions files
echo -e "\n=== Checking for dependabot config ==="
if [ -f .github/dependabot.yml ]; then
  cat .github/dependabot.yml
fi

# List all workflow files to see if there's anything else relevant
echo -e "\n=== All workflow files ==="
fd -t f '.yml$' .github/workflows/

Length of output: 2141

---

🌐 Web query:

GitHub Actions pull_request trigger bot token permissions restrictions

💡 Result:

Short summary — rules & restrictions for bot tokens on pull_request-triggered workflows:

• pull_request (from forks or untrusted actors): the automatically supplied GITHUB_TOKEN is restricted (no write to repo contents, no secrets). You cannot reliably grant write or secret access for runs from forks. (synacktiv.com)
• pull_request_target (runs in the base branch context): runs with the base ref’s permissions and can get write access and secrets unless you explicitly restrict permissions; but it can be dangerous because it executes with base-branch code — treat as untrusted if you check out PR code. (github.com)
• Dependabot PRs: treated like forked PRs for many events — GITHUB_TOKEN is read-only and secrets aren’t provided for those workflows. (github.blog)
• Repository / organization policy: admins can set default GITHUB_TOKEN permissions (read-only vs read/write) and can disable allowing Actions to create/approve PRs. Per-workflow permissions can still be set via the workflow permissions key, but those cannot escalate a forked pull_request run to gain write/secrets. (docs.github.com)

Recommended actions:

• Use pull_request_target only when you need write/secrets — but avoid checking out or executing untrusted PR code (or use a separate job that only performs safe API actions). (securitylab.github.com)
• Minimize GITHUB_TOKEN scopes in workflow permissions; set org defaults to the most restrictive option. (docs.github.com)

If you want, tell me your exact use case (bot actions needed: comment, push, approve, create PR?) and I’ll recommend the safest workflow pattern and sample permissions.

Citations:

• 1: https://www.synacktiv.com/publications/github-actions-exploitation-introduction?utm_source=openai
• 2: Security concern with using pull_request_target amannn/action-semantic-pull-request#182
• 3: https://github.blog/changelog/2021-02-19-github-actions-workflows-triggered-by-dependabot-prs-will-run-with-read-only-permissions?utm_source=openai
• 4: https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization?from=20423&from_column=20423&utm_source=openai
• 5: https://securitylab.github.com/resources/github-actions-building-blocks/?utm_source=openai
• 6: https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization?from=20423&from_column=20423&utm_source=openai

---

@tpantelis The issue is a GitHub Actions security restriction: pull_request events from bots (like Dependabot or submariner-bot) always get a read-only GITHUB_TOKEN, regardless of the permissions you set in your workflow. This is by design to prevent malicious code in bot PRs from having write access.

Solution: Use pull_request_target

Change your trigger from pull_request to pull_request_target. This runs the workflow in the context of the base branch (with full permissions) rather than the PR branch:

---
name: Test CodeRabbit

on:
  pull_request_target:

permissions:
  issues: write

jobs:
  test:
    uses: ./.github/workflows/coderabbit-trigger.yml
    with:
      pr_number: ${{ github.event.pull_request.number }}
    secrets: inherit

Key changes:

1. pull_request → pull_request_target
2. Hardcoded pr_number: 230 → pr_number: ${{ github.event.pull_request.number }}

Why this is safe

Using pull_request_target is safe in your case because:

• Your workflow only posts a comment via the GitHub API
• It doesn't check out or execute any code from the PR
• There's no risk of running malicious code from bot PRs

The issues: write permission will now work correctly because pull_request_target runs with full repository permissions (unless explicitly restricted).

/)/)
( •.•)
(") (") Ah-ha! Security restrictions...

---

✏️ Learnings added

Learnt from: tpantelis
URL: https://github.com/submariner-io/submariner-bot/pull/231

Timestamp: 2025-12-12T18:37:30.877Z
Learning: GitHub Actions workflows triggered by bot PRs (Dependabot, submariner-bot) using the `pull_request` trigger always receive a read-only GITHUB_TOKEN, regardless of permissions set in the workflow. To enable write permissions for bot PRs, use `pull_request_target` instead, which runs in the base branch context with full permissions. This is safe when the workflow only performs API actions without checking out or executing PR code.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.

[tpantelis]

@coderabbitai I added pull_request_target to the test calling workflow but it didn't trigger. Why?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check if the workflow files exist on the devel (base) branch
echo "=== Checking if workflows exist on devel branch ==="
git fetch origin devel 2>/dev/null || true
git ls-tree -r origin/devel --name-only | grep -E '\.github/workflows/(coderabbit-trigger|test-cr-trigger)\.yml' || echo "No matching workflows found on devel branch"

echo -e "\n=== Checking current branch files ==="
git branch --show-current
ls -la .github/workflows/

echo -e "\n=== Current content of test-cr-trigger.yml ==="
cat .github/workflows/test-cr-trigger.yml

echo -e "\n=== Git status of workflow files ==="
git status .github/workflows/

Length of output: 935

---

@tpantelis The workflow didn't trigger because pull_request_target runs workflows from the BASE branch (devel), not from the PR branch. Since these workflow files don't exist on the devel branch yet (they're only in your PR branch), GitHub can't find them to execute.

This is confirmed by checking the devel branch:

No matching workflows found on devel branch

Solution

You have a chicken-and-egg situation. Here are your options:

Option 1: Merge first, test later (Recommended)

1. Merge this PR to get the workflows onto the devel branch
2. Future bot PRs will then be able to use the pull_request_target workflow
3. You can verify it works with the next Dependabot or bot PR

Option 2: Test before merging

If you want to test before merging:

1. Push the workflow files directly to devel branch first (temporarily)
2. Then the workflow will trigger on this PR
3. After testing, you can proceed with merging this PR

Option 3: Use a different event for testing

For initial testing only, you could temporarily use workflow_dispatch to manually trigger the workflow:

on:
  workflow_dispatch:
    inputs:
      pr_number:
        description: 'PR number to comment on'
        required: true

Also note

Your pr_number is still hardcoded to 230. When you finalize, update it to:

pr_number: ${{ github.event.pull_request.number }}

Given this is a new workflow being introduced, Option 1 is the most practical — merge it and verify it works on the next bot PR.

---

🧠 Learnings used

Learnt from: tpantelis
Repo: submariner-io/submariner-bot PR: 0
File: :0-0
Timestamp: 2025-12-12T18:37:30.877Z
Learning: GitHub Actions workflows triggered by bot PRs (Dependabot, submariner-bot) using the `pull_request` trigger always receive a read-only GITHUB_TOKEN, regardless of permissions set in the workflow. To enable write permissions for bot PRs, use `pull_request_target` instead, which runs in the base branch context with full permissions. This is safe when the workflow only performs API actions without checking out or executing PR code.

[tpantelis]

@coderabbitai I changed the test workflow to use workflow_dispatch as you suggested but I don't see an option to run the workflow in the Actions tab

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check the current content of both workflow files
echo "=== test-cr-trigger.yml ==="
cat .github/workflows/test-cr-trigger.yml

echo -e "\n=== coderabbit-trigger.yml ==="
cat .github/workflows/coderabbit-trigger.yml

# Check which branch we're on and if the file exists on devel
echo -e "\n=== Current branch ==="
git branch --show-current

echo -e "\n=== Check if workflow exists on devel branch ==="
git fetch origin devel 2>/dev/null || true
git show origin/devel:.github/workflows/test-cr-trigger.yml 2>&1 | head -20 || echo "File does not exist on devel branch"

Length of output: 1884

---

@tpantelis The same issue applies here: workflow_dispatch workflows only appear in the Actions tab if the workflow file exists on the default branch (devel). Since test-cr-trigger.yml only exists on your PR branch, it won't show up.

This is confirmed by the output:

fatal: path '.github/workflows/test-cr-trigger.yml' exists on disk, but not in 'origin/devel'

Also, fix the pr_number

You have workflow_dispatch configured correctly with an input parameter, but you're not using it. Change this:

with:
  pr_number: 230

To:

with:
  pr_number: ${{ inputs.pr_number }}

Practical solutions

Option 1: Push directly to devel for testing (Quick test)

# Push just the workflow files to devel temporarily
git checkout devel
git checkout coderabbit_231 -- .github/workflows/coderabbit-trigger.yml .github/workflows/test-cr-trigger.yml
git commit -m "temp: add workflows for testing"
git push origin devel

Then:

1. Go to Actions tab → "Test CodeRabbit" workflow → "Run workflow"
2. Enter 231 as the PR number
3. Test it
4. Merge this PR to make it official

Option 2: Just merge and test naturally (Recommended)

Since this workflow is specifically for bot PRs:

1. Merge this PR now
2. Wait for the next Dependabot or submariner-bot PR
3. It will automatically trigger and post the CodeRabbit comment

I recommend Option 2 unless you need immediate verification. The workflow is straightforward and will work once merged.

---

🧠 Learnings used

Learnt from: tpantelis
Repo: submariner-io/submariner-bot PR: 0
File: :0-0
Timestamp: 2025-12-12T18:37:30.877Z
Learning: GitHub Actions workflows triggered by bot PRs (Dependabot, submariner-bot) using the `pull_request` trigger always receive a read-only GITHUB_TOKEN, regardless of permissions set in the workflow. To enable write permissions for bot PRs, use `pull_request_target` instead, which runs in the base branch context with full permissions. This is safe when the workflow only performs API actions without checking out or executing PR code.

[tpantelis]

@coderabbitai full review

[coderabbitai]

✅ Actions performed

Full review triggered.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

.github/workflows/coderabbit-trigger.yml (1)

17-18: Consider pinning actions/github-script to a commit SHA for supply-chain hardening.
Tags can move; pinning reduces risk.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ddcbec0 and 57a93eb.

📒 Files selected for processing (1)

• .github/workflows/coderabbit-trigger.yml (1 hunks)

🧰 Additional context used

🧠 Learnings (2)

📓 Common learnings

Learnt from: tpantelis
Repo: submariner-io/submariner-bot PR: 0
File: :0-0
Timestamp: 2025-12-12T18:37:30.877Z
Learning: GitHub Actions workflows triggered by bot PRs (Dependabot, submariner-bot) using the `pull_request` trigger always receive a read-only GITHUB_TOKEN, regardless of permissions set in the workflow. To enable write permissions for bot PRs, use `pull_request_target` instead, which runs in the base branch context with full permissions. This is safe when the workflow only performs API actions without checking out or executing PR code.

📚 Learning: 2025-12-12T18:37:30.877Z

Learnt from: tpantelis
Repo: submariner-io/submariner-bot PR: 0
File: :0-0
Timestamp: 2025-12-12T18:37:30.877Z
Learning: GitHub Actions workflows triggered by bot PRs (Dependabot, submariner-bot) using the `pull_request` trigger always receive a read-only GITHUB_TOKEN, regardless of permissions set in the workflow. To enable write permissions for bot PRs, use `pull_request_target` instead, which runs in the base branch context with full permissions. This is safe when the workflow only performs API actions without checking out or executing PR code.

Applied to files:

• .github/workflows/coderabbit-trigger.yml

🔇 Additional comments (1)

.github/workflows/coderabbit-trigger.yml (1)

13-15: Verify the submariner bot actor string; consider allowing the [bot] variant.
Depending on how the bot authenticates, github.actor may be submariner-bot[bot], so this job could silently never run.

[tpantelis]

@coderabbitai approve

[coderabbitai]

✅ Actions performed

Comments resolved and changes approved.

[submariner-bot]

🤖 Closed branches: [z_pr231/tpantelis/add-coderabbit-dependabot-workflow]