Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
yakimoto merged 2 commits into from
Aug 14, 2026
Merged

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

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
f946618
ci(qodo): adopt reusable OSS pr-agent review lane
yakimoto Aug 14, 2026
64315de
chore(qodo): pin reusable workflow to reviewed SHA
yakimoto Aug 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions .github/workflows/pr-agent.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# pr-agent (OSS) caller — adopts the wave-foundation reusable lane.
# Engine: OSS Qodo Merge on our OPENAI_KEY (trial-independent). SSOT pinned by SHA.
name: pr-agent (OSS)
on:
pull_request:
types: [opened, reopened, ready_for_review, synchronize]
issue_comment:
types: [created]
Comment on lines +7 to +8

@devin-ai-integration devin-ai-integration Bot Aug 14, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔍 issue_comment trigger fires on plain issues too, with no guard

The issue_comment: [created] trigger fires for comments on regular issues, not just pull requests. There is no if: condition (e.g. github.event.issue.pull_request) to limit the job to PR comments, so every comment on any issue in this repo starts a run of the reusable lane. Whether that is harmless depends entirely on guards inside wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml@150ffae, which is not visible in this repo — worth confirming that the reusable workflow itself short-circuits non-PR comments (and bot-authored comments), otherwise consider adding the guard here.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment on lines +7 to +8

@qodo-code-review qodo-code-review Bot Aug 14, 2026

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. Triggers on issue comments 🐞 Bug ➹ Performance

issue_comment events fire for both PRs and regular issues, and this workflow has no filter to
ensure it only runs for pull request comments. As a result, ordinary issue comments will also invoke
the PR-agent lane, creating unnecessary runs and noise.
Agent Prompt 
### Issue description
The workflow runs for comments on non-PR issues as well as PRs.

### Issue Context
`on: issue_comment` includes both issue and PR comments; PR comments are those where `github.event.issue.pull_request` is non-null.

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

### Suggested change
Add a job-level condition such as:
- `if: github.event_name != 'issue_comment' || github.event.issue.pull_request != null`
Or split into separate workflows so only PR comments trigger the agent.

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


permissions:
issues: write
pull-requests: write
contents: read
Comment on lines +10 to +13

@devin-ai-integration devin-ai-integration Bot Aug 14, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔍 Caller permissions rely on the reusable workflow's needs matching

Top-level permissions (issues/pull-requests write, contents read) are the effective ceiling for the called workflow; unlike .github/workflows/issue-ops-triage.yml:13-15 no job-level permissions block is declared here. This works only if the reusable lane needs no additional scopes (e.g. contents: write for suggested-commit features). Worth verifying against wave-foundation/.github/workflows/reusable-pr-agent.yml.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment thread
devin-ai-integration[bot] marked this conversation as resolved.

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

jobs:
pr_agent:
uses: wave-av/wave-foundation/.github/workflows/reusable-pr-agent.yml@150ffae24f63e207ab81430fa64cb2b1e5c01546 # post-#1191
secrets:
OPENAI_KEY: ${{ secrets.OPENAI_KEY }}
Comment on lines +20 to +23

@devin-ai-integration devin-ai-integration Bot Aug 14, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🔴 New review automation workflow can never run in this public repository

The new automation is wired to a helper workflow that lives in a private repository (uses: wave-av/wave-foundation/...@main at .github/workflows/pr-agent.yml:22), which this public repository is not permitted to load, so the automation silently does nothing on every pull request.
Impact: The PR review bot never comments; runs finish instantly with no jobs and no error visible to authors.

Why the cross-repo call fails: public repo consuming a private reusable workflow

.github/workflows/foundation-gate.yml:1-10 documents this exact constraint for this repo: "this repo is PUBLIC; wave-av/wave-foundation is PRIVATE. GitHub Actions does NOT permit a public repo to consume a private repo's reusable workflow — the call fails in 0s with 0 jobs". That is why checks.yml was inlined as .github/workflows/_checks.yml. The new pr-agent.yml reintroduces the private cross-repo uses: pattern, so it will hit the same failure mode. Options: inline the lane locally (as done for the gate), or make the reusable workflow's repo public/internal.

Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Comment thread
devin-ai-integration[bot] marked this conversation as resolved.
Comment on lines +22 to +23

@qodo-code-review qodo-code-review Bot Aug 14, 2026

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. Ungated secret-backed comment runs 🐞 Bug ⛨ Security

Any issue_comment creation triggers this workflow and supplies OPENAI_KEY to the called job,
with no caller-side gating on comment content or author trust. This enables unauthorized triggering
of secret-backed runs (cost/abuse risk) and increases the blast radius if the called workflow
mishandles untrusted inputs.
Agent Prompt 
### Issue description
The workflow triggers on every `issue_comment` and passes `OPENAI_KEY` into the reusable workflow without any restrictions. This allows untrusted users (anyone who can comment) to trigger secret-backed runs.

### Issue Context
Even if the reusable workflow has internal checks, caller-side gating is a key defense-in-depth control because the secret is being provided by the caller.

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

### Suggested change
Add a job-level `if:` (or split workflows) to restrict execution to intended, trusted invocations, e.g.:
- Only run on PR comments: `github.event.issue.pull_request != null`
- Only run on an explicit command prefix in the comment body (e.g. `/pr-agent`)
- Only allow trusted actors: `github.event.comment.author_association` in `OWNER|MEMBER|COLLABORATOR`
Optionally, avoid providing `OPENAI_KEY` on comment-triggered runs unless the above checks pass.

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

Loading