Skip to content

ci(qodo): adopt reusable OSS pr-agent review lane - #33

Merged
yakimoto merged 1 commit into
mainfrom
qodo/oss-ci
Aug 14, 2026
Merged

ci(qodo): adopt reusable OSS pr-agent review lane#33
yakimoto merged 1 commit into
mainfrom
qodo/oss-ci

Conversation

@yakimoto

@yakimoto yakimoto commented Aug 14, 2026

Copy link
Copy Markdown
Contributor

Fleet rollout of the OSS Qodo Merge lane (wave-foundation reusable workflow, OPENAI_KEY secret, auto review+improve with committable suggestions). Reference impl + rationale: wave-gateway#923 + qodo-trial memo. Auto-approve labeled, auto-merge armed.


View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.


Open in Devin Review

Note

Low Risk
CI-only addition following the same reusable-workflow pattern as other fleet workflows; no application code or runtime behavior changes in this repo.

Overview
Adds a caller workflow at .github/workflows/pr-agent.yml so this repo runs the fleet-standard OSS Qodo Merge lane from wave-av/wave-foundation (reusable-pr-agent.yml@main), wired with the repo OPENAI_KEY secret.

Triggers on PR lifecycle events (opened, reopened, ready_for_review, synchronize) and new issue comments, with concurrency keyed to the PR/issue so in-flight runs cancel on updates. Grants issues: write, pull-requests: write, and contents: read for automated review/improve behavior defined in the reusable workflow.

Reviewed by Cursor Bugbot for commit f08ec1c. Bugbot is set up for automated code reviews on this repo. Configure here.

Review in cubic

@yakimoto yakimoto added the auto-approve Opts a maintainer PR into the reviewbot auto-approve circuit breaker label Aug 14, 2026
@yakimoto
yakimoto enabled auto-merge August 14, 2026 16:29
@cubic-dev-ai

cubic-dev-ai Bot commented Aug 14, 2026

Copy link
Copy Markdown

Running ultrareview automatically — New CI workflow grants write permissions, passes a production secret to a reusable workflow, and auto-engages on PRs — a subtle misconfig could leak the key or modify PRs, so we're running an ultrareview.. I'll post findings when complete.

@coderabbitai

coderabbitai Bot commented Aug 14, 2026

Copy link
Copy Markdown

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 17 minutes

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 66710988-a608-4c14-969d-c6c5b458bbd5

📥 Commits

Reviewing files that changed from the base of the PR and between 7767662 and f08ec1c.

📒 Files selected for processing (1)
  • .github/workflows/pr-agent.yml

Comment @coderabbitai help to get the list of available commands.

@yakimoto
yakimoto merged commit 75c20fb into main Aug 14, 2026
12 of 13 checks passed
@yakimoto
yakimoto deleted the qodo/oss-ci branch August 14, 2026 16:30
@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

CI: add OSS pr-agent workflow using wave-foundation reusable lane

⚙️ Configuration changes 🕐 Less than 10 minutes

Grey Divider

AI Description

• Add a PR/comment-triggered GitHub Actions workflow to run OSS Qodo pr-agent.
• Delegate execution to the wave-foundation reusable workflow (SSOT) with repo-level permissions.
• Pass OPENAI_KEY secret and enforce per-PR concurrency with cancel-in-progress.
Diagram

graph TD
  A{{"PR event / Comment"}} --> B[".github/workflows/pr-agent.yml"] --> C["Reusable workflow\nwave-foundation/reusable-pr-agent.yml@main"] --> D[("OPENAI_KEY secret")]

  subgraph Legend
    direction LR
    _evt{{"Trigger"}} ~~~ _wf["Workflow"] ~~~ _reuse["Reusable workflow"] ~~~ _sec[("Secret")]
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Pin reusable workflow to a release tag/commit SHA
  • ➕ Prevents unexpected behavior changes from upstream main updates
  • ➕ Improves auditability and incident rollback
  • ➖ Requires periodic bump PRs to stay current
  • ➖ Slightly more maintenance overhead across repos
2. Vendor the pr-agent workflow logic locally
  • ➕ Full control over behavior and rollout timing
  • ➕ No dependency on upstream repository availability or changes
  • ➖ Drifts across repos; harder fleet-wide consistency
  • ➖ More duplicated maintenance and bugfix effort

Recommendation: Using the wave-foundation reusable workflow is the right fleet-scale choice for consistency and central maintenance. Consider pinning @main to a tag or commit SHA to reduce supply-chain and change-management risk, while still keeping the caller workflow minimal.

Files changed (1) +24 / -0

Other (1) +24 / -0
pr-agent.ymlAdd reusable OSS pr-agent caller workflow (PR + comment triggers) +24/-0

Add reusable OSS pr-agent caller workflow (PR + comment triggers)

• Introduces a GitHub Actions workflow that runs on pull_request activity and issue_comment creation, with write permissions for issues/PRs and read for contents. Configures per-PR concurrency with cancel-in-progress and delegates execution to wave-foundation's reusable pr-agent workflow, passing the OPENAI_KEY secret.

.github/workflows/pr-agent.yml

@cubic-dev-ai

cubic-dev-ai Bot commented Aug 14, 2026

Copy link
Copy Markdown

I can't run this ultrareview because your workspace has reached its monthly review limit. cubic has reviewed 100,145 of the 100,000 allowed lines of code this month. Reviews resume on 4 September 2026 (in 22 days). Enable flex capacity to cover overages automatically and resume reviews now. Learn how flex capacity works.

To help optimise your usage, you can tune cubic to get the most out of your usage limits:

Learn more →

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 6 potential issues.

Open in Devin Review

@qodo-code-review

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Action required

1. Unpinned workflow reference 🐞 Bug ⛨ Security
Description
The workflow calls the reusable workflow with the floating ref "@main", so future upstream changes
can silently alter what executes here (including under this repo’s permissions/secrets). This
undermines reviewability and increases supply-chain risk versus the SHA-pinned pattern used
elsewhere in this repo.
Code

.github/workflows/pr-agent.yml[R21-23]

+  pr_agent:
+    uses: wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml@main
+    secrets:
Evidence
The new workflow uses @main, while an existing workflow in the same repo demonstrates the expected
SHA-pinning practice for reusable workflows (and even pins a scripts_ref). The repo also documents
determinism/pinning as an explicit security property in another workflow.

.github/workflows/pr-agent.yml[20-24]
.github/workflows/issue-ops-triage.yml[15-22]
.github/workflows/public-repo-guard.yml[9-15]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The caller workflow references `wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml@main`, which is a mutable ref. This allows the executed workflow to change without a reviewed change in this repo.

### Issue Context
Other workflows in this repo pin reusable workflows/actions to specific commit SHAs for determinism and supply-chain hardening.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[20-24]
- .github/workflows/issue-ops-triage.yml[15-22]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Secret-bearing comment trigger 🐞 Bug ⛨ Security
Description
The workflow is triggered by issue_comment (created) without any caller-side guard ensuring the
comment is on a PR or that the actor is trusted, yet it forwards OPENAI_KEY into the called
workflow. This allows any commenter to invoke a secret-enabled run (including on non-PR issues),
increasing the chance of misuse if the callee processes attacker-controlled content.
Code

.github/workflows/pr-agent.yml[R6-9]

+  pull_request:
+    types: [opened, reopened, ready_for_review, synchronize]
+  issue_comment:
+    types: [created]
Evidence
The workflow explicitly triggers on all created issue comments and forwards OPENAI_KEY to the
reusable workflow, but contains no conditional logic to require PR comments or trusted actors, so
the invocation surface is widened to any issue comment event.

.github/workflows/pr-agent.yml[5-9]
.github/workflows/pr-agent.yml[20-24]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`issue_comment` triggers run in the base repository context and this caller forwards `OPENAI_KEY` to the reusable workflow. Without a caller-side `if:` guard, any user can trigger the workflow by commenting, including on regular issues (not just PRs).

### Issue Context
Even if the reusable workflow includes its own checks, this caller currently provides no protection or scoping. The safest pattern is to restrict the event scope and actor trust at the caller boundary.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[5-9]
- .github/workflows/pr-agent.yml[20-24]

### Suggested direction
- Add a job-level `if:` that requires PR context for `issue_comment` (e.g., `github.event.issue.pull_request != null`).
- Add a trust-tier check (e.g., `github.event.comment.author_association` in `OWNER|MEMBER|COLLABORATOR`).
- Consider not passing `OPENAI_KEY` for untrusted events, or splitting into separate jobs/workflows for trusted vs untrusted triggers.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

3. Insufficient contents permission 🐞 Bug ≡ Correctness
Description
The workflow grants contents: read, which prevents using the default GITHUB_TOKEN to push
commits to branches; if the reusable pr-agent lane is expected to create committable fixes, it will
be blocked or forced into a degraded mode. This should be aligned with the intended behavior and the
trust model of the triggers.
Code

.github/workflows/pr-agent.yml[R11-15]

+permissions:
+  issues: write
+  pull-requests: write
+  contents: read
+
Evidence
The caller explicitly limits contents to read, while the workflow’s own header comment states the
lane is intended to do “auto review+improve with committable suggestions,” which typically requires
repository write capability to push commits.

.github/workflows/pr-agent.yml[1-4]
.github/workflows/pr-agent.yml[11-15]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The caller sets `permissions: contents: read`. If the reusable workflow tries to push commits ("committable suggestions"), those operations will fail when using `GITHUB_TOKEN`.

### Issue Context
Raising `contents` to `write` is only safe if the workflow is properly gated (especially for `issue_comment`). Alternatively, keep `contents: read` and ensure the lane only comments/reviews without pushing.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[11-15]
- .github/workflows/pr-agent.yml[5-9]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context
✅ Compliance rules (platform): 7 rules
Review mode: ⚖️ Balanced: This adds a privileged CI workflow that invokes a remote reusable workflow, passes an OpenAI secret, and enables PR/issue write permissions and automation; despite being localized, it warrants a careful security and behavior review.

Grey Divider

Tip of the day
💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment on lines +21 to +23
pr_agent:
uses: wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml@main
secrets:

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Unpinned workflow reference 🐞 Bug ⛨ Security

The workflow calls the reusable workflow with the floating ref "@main", so future upstream changes
can silently alter what executes here (including under this repo’s permissions/secrets). This
undermines reviewability and increases supply-chain risk versus the SHA-pinned pattern used
elsewhere in this repo.
Agent Prompt
### Issue description
The caller workflow references `wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml@main`, which is a mutable ref. This allows the executed workflow to change without a reviewed change in this repo.

### Issue Context
Other workflows in this repo pin reusable workflows/actions to specific commit SHAs for determinism and supply-chain hardening.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[20-24]
- .github/workflows/issue-ops-triage.yml[15-22]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +6 to +9
pull_request:
types: [opened, reopened, ready_for_review, synchronize]
issue_comment:
types: [created]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Secret-bearing comment trigger 🐞 Bug ⛨ Security

The workflow is triggered by issue_comment (created) without any caller-side guard ensuring the
comment is on a PR or that the actor is trusted, yet it forwards OPENAI_KEY into the called
workflow. This allows any commenter to invoke a secret-enabled run (including on non-PR issues),
increasing the chance of misuse if the callee processes attacker-controlled content.
Agent Prompt
### Issue description
`issue_comment` triggers run in the base repository context and this caller forwards `OPENAI_KEY` to the reusable workflow. Without a caller-side `if:` guard, any user can trigger the workflow by commenting, including on regular issues (not just PRs).

### Issue Context
Even if the reusable workflow includes its own checks, this caller currently provides no protection or scoping. The safest pattern is to restrict the event scope and actor trust at the caller boundary.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[5-9]
- .github/workflows/pr-agent.yml[20-24]

### Suggested direction
- Add a job-level `if:` that requires PR context for `issue_comment` (e.g., `github.event.issue.pull_request != null`).
- Add a trust-tier check (e.g., `github.event.comment.author_association` in `OWNER|MEMBER|COLLABORATOR`).
- Consider not passing `OPENAI_KEY` for untrusted events, or splitting into separate jobs/workflows for trusted vs untrusted triggers.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +11 to +15
permissions:
issues: write
pull-requests: write
contents: read

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

3. Insufficient contents permission 🐞 Bug ≡ Correctness

The workflow grants contents: read, which prevents using the default GITHUB_TOKEN to push
commits to branches; if the reusable pr-agent lane is expected to create committable fixes, it will
be blocked or forced into a degraded mode. This should be aligned with the intended behavior and the
trust model of the triggers.
Agent Prompt
### Issue description
The caller sets `permissions: contents: read`. If the reusable workflow tries to push commits ("committable suggestions"), those operations will fail when using `GITHUB_TOKEN`.

### Issue Context
Raising `contents` to `write` is only safe if the workflow is properly gated (especially for `issue_comment`). Alternatively, keep `contents: read` and ensure the lane only comments/reviews without pushing.

### Fix Focus Areas
- .github/workflows/pr-agent.yml[11-15]
- .github/workflows/pr-agent.yml[5-9]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@qodo-code-review

Copy link
Copy Markdown

Qodo Fixer

✅ Merged (0) · ☑ Fixed (0)

Process

  • ⏭ Skipped (1)

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

Fix All in Cursor

Bugbot Autofix is ON, but it could not run because the branch was deleted or merged before autofix could start.

Reviewed by Cursor Bugbot for commit f08ec1c. Configure here.


concurrency:
group: pr-agent-${{ github.event.pull_request.number || github.event.issue.number || github.ref }}
cancel-in-progress: true

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comments cancel in-progress reviews

High Severity

The concurrency group is shared across pull_request and issue_comment with cancel-in-progress enabled, so any new comment cancels an in-flight auto review. A non-command comment then no-ops, and the review never completes.

Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit f08ec1c. Configure here.

pull_request:
types: [opened, reopened, ready_for_review, synchronize]
issue_comment:
types: [created]

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Untrusted comments invoke paid agent

Medium Severity

issue_comment starts this lane with OPENAI_KEY and write permissions for every comment on this public repository, including outsiders and non-PR issues. Untrusted users can invoke the agent and consume the org key.

Additional Locations (1)
Fix in Cursor Fix in Web

Reviewed by Cursor Bugbot for commit f08ec1c. Configure here.

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Risk: high. Left a non-blocking comment and did not approve; no reviewers were assigned. Cursor Bugbot skipped as a check and reported two unresolved findings that need human review.

Open in Web View Automation 

Sent by Cursor Approval Agent: Pull Request Router and Approver

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

auto-approve Opts a maintainer PR into the reviewbot auto-approve circuit breaker

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant