feat: implement issue #333 — [Fleet Monitor] petry-projects/ContentTwin — .github/workflows/pr-review-mention.yml - #336
Conversation
…in — .github/workflows/pr-review-mention.yml
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the BATS tests for the pr-review-mention workflow to align with a concurrency fix (issue #333) that sets cancel-in-progress to false and keys the concurrency group on both the event name and the PR/issue number. The feedback suggests refactoring a Python one-liner assertion in the tests to assign the cancel-in-progress value to a local variable, which avoids complex nested quote escaping and improves readability.
There was a problem hiding this comment.
Pull request overview
This pull request addresses issue #333 by adjusting the concurrency strategy in the pr-review-mention workflow so that bursts of comment/review events no longer generate “0-job failure” runs that inflate Fleet Monitor’s failure rate.
Changes:
- Updated
.github/workflows/pr-review-mention.ymlconcurrency to usecancel-in-progress: falseand a group keyed bygithub.event_nameplus PR/issue number to avoid cross-cancellation. - Updated the Bats guard tests to validate the new concurrency behavior and group keying.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
.github/workflows/pr-review-mention.yml |
Switches concurrency to avoid startup-failure cancellations and scopes groups by event + conversation number. |
scripts/tests/pr-review-mention-workflow.bats |
Updates workflow guards to assert cancel-in-progress: false and validate the new group key components. |
Dev-Lead — review-changes (applied)Changes committed and pushed. |
|
Warning Review limit reached
Next review available in: 22 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Dev-Lead — review-changes (no-changes)No changes were needed for this PR. |
donpetry-bot
left a comment
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: MEDIUM
Reviewed commit: 21352db8ca27a7566b032518d284da78cc03cbb7
Review mode: triage-approved (single reviewer)
Summary
Fixes issue #333 (Fleet Monitor 50% failure rate on pr-review-mention.yml) by switching workflow concurrency to cancel-in-progress: false with a group keyed on event name + PR/issue number, so superseded pending reusable-caller runs are recorded as clean cancellations instead of 0-job startup failures. Mirrors the validated add-to-project.yml fix (#331). Guard tests updated accordingly. All CI green, sole review thread resolved.
Linked issue analysis
Linked issue #333 reports a 50% failure rate (43/86 runs) on pr-review-mention.yml, caused by the prior #323 fix: cancel-in-progress: true cancelled pending reusable-caller runs, which GitHub records as startup failures (0 jobs). This PR substantively addresses the root cause — cancel-in-progress: false makes superseded runs record as clean 'cancelled', and keying the group on github.event_name + issue/PR number prevents cross-cancellation between distinct event types and unrelated conversations. Dropping the github.ref fallback is safe: every triggering event carries issue.number or pull_request.number.
Findings
No blocking findings.
- Workflow change is concurrency-only; permissions: {} unchanged, no new actions or secrets, actionlint (Lint) passed. The multiline >- folded expression is a standard Actions pattern and validated by CI.
- Bats guard tests correctly updated to assert cancel-in-progress: false and event+conversation group keying, including gemini-code-assist's readability suggestion (local variable extraction) — thread resolved.
- Secret scanning MCP tool unavailable in this environment; gitleaks CI check passed and the diff contains no secret-like content.
CI status
All required checks green: CI (Lint, Format, Test, gitleaks secret scan), CodeQL, SonarCloud Quality Gate passed (0 new issues, 0 security hotspots), AgentShield, dependency-audit (ecosystem jobs skipped as expected — no matching manifests changed), CodeRabbit success. Mergeable; merge state BLOCKED only pending required review.
Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.
Closes #333
Implemented by dev-lead agent. Please review.