qodo-gate: re-evaluate when Qodo posts its review comment

[widgetii]

Problem

Found by Qodo's own review of #2269 — a correct finding against the fix in that PR.

#2269 taught the gate to accept an issue comment headed Code Review by Qodo as proof of review, since that is the only proof a zero-finding PR ever produces. It did not give the workflow a reason to look again when that comment arrives.

So the gap only moved:

1. PR opens → qodo-gate runs → Qodo has not answered yet → fail (correct)
2. Qodo posts Code Review by Qodo a minute or two later — as an issue comment
3. issue_comment was not a trigger, so nothing re-evaluates the gate
4. The required check stays red until an unrelated push

The irony is that #2269 could not have caught this itself: it went green because I pushed a second commit, which re-triggered the gate at a point where the comment already existed. A synchronize event masked a missing issue_comment event.

Fix

Adds the issue_comment trigger, plus the plumbing that payload requires:

• A job guard. issue_comment also fires for plain issues, which have no PR to gate. Every other trigger here is PR-only, so github.event_name != 'issue_comment' || github.event.issue.pull_request is the whole condition.
• PR number from github.event.issue.number. issue_comment carries issue, not pull_request; for a comment on a PR the issue number is the PR number.
• Head sha resolved at runtime in the sweep step. It read github.event.pull_request.head.sha, which issue_comment does not carry. Now looked up from the PR when empty, and still best-effort — a failed lookup skips the sweep rather than turning a PASS into a FAIL.

The sweep matters most on exactly this trigger: it is the one that clears a clean PR's earlier red run off the head commit, which branch protection's rollup would otherwise keep counting.

Evidence

Review configuration only; nothing enters an image.

• Root cause is reproducible by inspection: on: had no issue_comment, while the detection logic added in qodo: unbreak the config loader, and stop the gate blocking clean PRs #2269 depends on a comment.

• Workflow parses; triggers are pull_request, pull_request_review, pull_request_review_comment, issue_comment; both steps resolve PR from either payload shape.

• This PR cannot test the path it fixes, and its own gate will stay red. I initially expected it to self-heal; it will not. GitHub runs issue_comment-triggered workflows from the default branch, not from the PR head — so the new trigger is inert until this merges. Observed directly here: Qodo posted PR Summary by Qodo (an issue comment) at 16:01:26Z and no qodo-gate run appeared for it; the only run is the pull_request one that failed at open. The same is true of the pull_request_review triggers, which is why those runs sat queued forever on qodo: review standards, compliance gates, and a PR template #2268 while only pull_request runs completed.

  So merging this needs the same manual nudge qodo: unbreak the config loader, and stop the gate blocking clean PRs #2269 needed — a push, or the skip-qodo-gate label. That is the bootstrap problem in a sentence: the fix for "the gate cannot self-heal" cannot itself self-heal.

  Real verification is the first clean PR opened after this merges: its qodo-gate should go red at open and turn green on its own once Qodo comments, with no push. If it stays red, this fix is wrong.

Also confirmed while verifying #2269's merge: the .pr_agent.toml loader fix works. A /review on master's config produced a normal review with no failed to apply 'local' repo settings comment, so the custom standards are live for the first time.

Scope

• No kernel patches, no single-board files, no debugging tooling
• Nothing under general/overlay/; no package sources changed
• No code — CI workflow only, does not enter any image

🤖 Generated with Claude Code

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Re-run qodo-gate when Qodo posts its PR review comment

🐞 Bug fix ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Trigger qodo-gate on PR issue comments so Qodo’s review can flip the check green.
• Guard issue_comment runs to ignore non-PR issues.
• Resolve PR number and head SHA for issue_comment payloads to keep the sweep safe.

Diagram

graph TD
  A["GitHub events"] --> B["qodo-gate workflow"] --> C["Require Qodo review"] --> D[("GitHub API")]
  B --> E["Sweep reruns"] --> D

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Scheduled re-check (cron) for recent PRs

• ➕ Decouples re-evaluation from event payload quirks
• ➕ Catches edge cases where events are missed/delivered late
• ➖ Adds latency (not immediate on Qodo comment)
• ➖ Wastes CI cycles scanning PRs
• ➖ More complex filtering/state tracking

2. Use pull_request_target + comment trigger to always have PR context

• ➕ Always has access to PR metadata (head SHA/number) without extra lookup
• ➖ Higher security risk surface (runs in base repo context)
• ➖ Still needs careful guarding to avoid untrusted code execution

Recommendation: Keep the current approach: add issue_comment as the missing trigger, guard it to PR-only, and do a best-effort head SHA lookup for the sweep. It’s the smallest change that fixes the real failure mode (no re-evaluation when Qodo posts the only proof of a zero-finding review) while explicitly avoiding turning transient API/lookups into new failures.

Files changed (1) +25 / -1

Bug fix (1) +25 / -1

qodo-gate.ymlTrigger qodo-gate on issue comments and add PR-context plumbing +25/-1

Trigger qodo-gate on issue comments and add PR-context plumbing

• Adds issue_comment (created/edited) as a workflow trigger so Qodo’s review comment can re-run the gate. Guards the job to skip plain issues, derives PR number from the issue payload, and resolves HEAD_SHA via gh pr view when the issue_comment event lacks pull_request fields (skipping the sweep if lookup fails).

.github/workflows/qodo-gate.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Unrestricted comment-triggered gate ✓ Resolved 🐞 Bug ⛨ Security

Description

issue_comment now triggers the gate for any PR comment (created/edited) because the job guard only
checks that the issue is a PR, not that the comment is from Qodo or relevant. This allows any
permitted commenter to repeatedly run an API-heavy workflow (and its rerun sweep with `actions:
write`), increasing CI noise and the chance of rate-limit/transient failures affecting a required
check.

Code

.github/workflows/qodo-gate.yml[R65-67]

+    # issue_comment fires for plain issues too, which have no PR to gate.
+    # Every other trigger here is PR-only, so this is the whole guard.
+    if: github.event_name != 'issue_comment' || github.event.issue.pull_request

Evidence

The new issue_comment trigger plus a PR-only guard means any PR comment edit/creation can run the
workflow. Because the workflow also has actions: write and explicitly reruns failed runs,
unrelated commenters can repeatedly invoke expensive API calls and rerun attempts.

.github/workflows/qodo-gate.yml[41-55]
.github/workflows/qodo-gate.yml[57-67]
.github/workflows/qodo-gate.yml[194-229]

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 workflow is triggered by `issue_comment` events for pull requests, but the job-level guard only excludes plain issues. This means **any** PR comment (created/edited) can run the gate and its sweep step, even when unrelated to Qodo, increasing CI/API load and potential abuse.
### Issue Context
You want re-evaluation specifically when Qodo posts/edits its "Code Review by Qodo" issue comment. The workflow currently has `actions: write` and performs API-heavy calls plus reruns of failed runs, so it’s better to restrict `issue_comment` runs to the relevant actor/content.
### Fix Focus Areas
- .github/workflows/qodo-gate.yml[54-67]
### Suggested change
Tighten the job `if:` so `issue_comment` runs only when:
- the issue is a PR, **and**
- the comment is authored by Qodo’s bot login (or startsWith it), and optionally
- the comment body matches the review header (case-insensitive) to avoid running on Qodo’s non-review chatter.
Example:

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

---

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[widgetii]

Fixed in the latest push — a fair catch, and I had left the guard doing only half its job.

The guard established that the commented-on thing was a PR, and stopped there. So issue_comment fired for any comment by anyone: a required check turned into an API-heavy workflow holding actions: write, runnable at will.

It now also requires the comment to be the bot's and to carry the Code Review by Qodo header:

• author — only Qodo's own comment is evidence that Qodo reviewed. A human typing /review still works, because Qodo answers and that answer is what triggers the gate.
• body — the bot also posts Qodo is busy working (written before it has read anything) and PR Summary by Qodo (/describe output). Neither means the diff was reviewed, and matching the header also cuts three runs per review down to one.

On your severity framing: I agree it is worth fixing, though the practical exposure was bounded — pull_request already re-runs this on every push, so a determined commenter had a cheaper lever already. The stronger argument is the one you make about a required check: extra failure surface there is a merge blocker, not just noise.