v1.2.0: π reaction on requests + rename comment trigger to /orca-code-review - #6
Conversation
Static one-shot reaction so the requester sees the bot noticed the trigger. On every event, react on the PR body (issue reactions endpoint β PRs are issues). For issue_comment triggers (/orcarouter-review), also react on the trigger comment so a maintainer sees direct feedback on THEIR comment. Uses gh api with inputs.github-token (issues: write + pull-requests: write already granted in the example workflow). Reaction outages are non-fatal: the review must never be blocked by a UI-affordance failure. Placed after Resolve PR refs (PR number available) and before any skip gate, so even a skipped run still visibly acknowledges receipt. Reactions API POST is idempotent, so re-runs (synchronize) don't duplicate. Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
Matches the shipped brand (Orca-Code-Review). Legacy /orcarouter-review was left over from the pre-rebrand naming and confused new consumers about what command actually re-runs the review. Applies the rename in the example workflow's issue_comment `if:` gate, the SECURITY.md threat-model section, the action's input-description prose, the README, and one comment in the settings unit test. No runtime code depends on the exact string outside the workflow's `if:` gate itself, so no gate-logic change is needed. Consumers with the previous workflow copy must update the trigger string in their `.github/workflows/*.yml` to /orca-code-review. Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
There was a problem hiding this comment.
π‘ Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2e644f6b60
βΉοΈ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with π.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| `βΈοΈ **Automatic review is off for this PR** (${process.env.REASON}).\n\n` + | ||
| `The check **passes** β this never blocks your merge. A maintainer can still ` + | ||
| `run a review on demand by commenting \`/orcarouter-review\`, or change the ` + | ||
| `run a review on demand by commenting \`/orca-code-review\`, or change the ` + |
There was a problem hiding this comment.
Preserve the old trigger in skip notices
For repos that upgrade the floating @v1 action but keep the previously copied workflow gate, issue_comment still only matches /orcarouter-review; this action cannot update that consumer-owned if:. When a settings skip happens (auto_review=false, on_demand, draft, or author allowlist), this PR comment now tells maintainers to use /orca-code-review, which those existing workflows will ignore, so the advertised on-demand escape hatch does not work. Consider mentioning both triggers or making the displayed trigger configurable.
Useful? React with πΒ / π.
Orca-Code-Review β push 1
Tier: STRONG (final pass) β pass
β no blocking findings
Summary
Compatibility
startsWith(...)gate lives in the consumer's workflow. Existing workflows on /orcarouter-review keep working (their local string still matches their ownif:). Consumers who copy the updated example workflow will now use /orca-code-review.Test plan
feat/eyes-reactionverified end-to-end on ZhenghuaBao/Code-Review-Test PR chore: rename example workflow to orca-code-review.yml (v1.2.1)Β #7:github-actions[bot])./orca-code-reviewtrigger recognised (job started, no moreskipped in 1s).π€ Generated with Claude Code