feat(groom): pilot ci-groom.yml caller — groomer-only, dry-run parity dispatch (BE-3873)#53
Conversation
… dispatch (BE-3873) Enroll this repo as the first groom pilot (Groom Phase 3). A thin caller pins the merged reusable groom.yml by full commit SHA, runs weekly on schedule (never on-PR) in groomer-only mode (finds + files `groom`-labeled GitHub issues; no commits/PRs/builder), and adds a manual dispatch with a dry_run toggle for spot-checking parity against a studio groom run before trusting live filing. Files issues as cloud-code-bot (App identity already provisioned here for cursor-review), so the caller needs no issues:write of its own.
mattmillerai
added
agent-coded
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 5 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: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
🔍 Cursor Review — Consolidated panel
Triggered by @mattmillerai.
Found 3 finding(s).
| Severity | Count |
|---|---|
| 🟠 High | 1 |
| 🟡 Medium | 1 |
| 🟢 Low | 1 |
Panel: 8/8 reviewers contributed findings.
…on dry-run (BE-3873)
Address cursor-review panel findings on the ci-groom.yml pilot caller:
- High: the caller declared `concurrency: groom-${{ github.repository }}`
identical to the reusable groom.yml's own top-level group with
cancel-in-progress:false. The caller run holds that group while its reusable
`uses:` job waits to acquire the same group -> self-deadlock, run hangs to
timeout, nothing filed. The reusable already serializes per-repo across ALL
callers, so the caller block was redundant; remove it and document why the
caller must stay out of the group.
- Medium: a manual dry-run dispatch inherited the reusable's default
volume_gate:true + cadence:7, so a quiet week silently skipped the audit and
produced no parity summary — defeating the Phase 3 dry-run parity gate. Pass
volume_gate: ${{ github.event.inputs.dry_run != 'true' }} so a dry-run always
runs the full audit while live/scheduled runs keep the gate.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
ELI-5
The "groom" bot used to only run on Matt's Mac Studio, hunting a repo for
tidy-up work (duplication, dead code, complexity) and filing it as tickets.
Phase 2 turned that bot into a reusable GitHub Actions workflow (
groom.yml)that lives in this repo. This PR adds the first caller that switches it on
for one real repo — this one — so we can prove it works in CI before rolling
it out anywhere else. It runs once a week, files
groom-labeled GitHub issues,and can be dry-run by hand to eyeball its findings first. It never writes code,
opens PRs, or merges anything — finds only.
What this PR does
Adds
.github/workflows/ci-groom.yml: a thin, SHA-pinned caller of the reusablegroom.yml(landed in #49 / BE-3872), enrollinggithub-workflowsitself asthe first groom pilot repo (Groom Phase 3, BE-3873).
groom-labeled GitHub issues —no commits, no PRs, no auto-builder, never merges. Zero prod risk.
workflow_dispatchwith a
dry_runtoggle to spot-check parity against a studio groom run onthe same commit before trusting live filing.
07154fb, the merge that addedgroom.yml+the
.github/groom/briefs/ledger) withworkflows_refkept in lock-step, sothe run always loads the briefs that match the workflow filing them.
vars.APP_ID+secrets.CLOUD_CODE_BOT_PRIVATE_KEY,already provisioned here for cursor-review), so groom's issues are a distinct,
queryable actor and the caller keeps
contents: readleast-privilege.cadence: 7matches the weekly cron, so a week with nothingmerged skips the expensive audit.
Why this repo as the pilot (judgment call — Matt, your veto)
The ticket suggests
Comfy-Org/comfy-toolboxor another low-risk repo youpick. I piloted on
github-workflowsitself because:ci-cursor-review.yml,ci-detect-unreviewed-merge.yml) —ci-groom.ymlis the exact sameself-enrollment pattern, lowest-friction and lowest-risk.
whichever repo hosts it.
If you'd rather pilot on
comfy-toolbox(it's active and already anagents-md-integritycaller, so enrolling it is trivial), this same file dropsin verbatim — say the word and I'll retarget. Either way, live issue-filing
begins only after this merges to the default branch (GitHub only runs
scheduled workflows from the default branch).
Acceptance criteria — status (read before merging)
This ticket is a ~1–2 week pilot, so it splits into a code artifact (this PR)
and operational follow-ups that need runtime data no single PR can produce:
ci-groom.ymlcaller producing scheduled findings. Thecaller is complete and validated (YAML parses; every
with:/secrets:keymatches
groom.yml's declared contract). Findings begin firing once (a) thismerges to the default branch and (b) the
ANTHROPIC_API_KEYprerequisitebelow is satisfied.
(no re-filing) is already implemented + unit-tested in the Phase 2 ledger
(
.github/groom/ledger.py,test_ledger.py). The parity observationagainst studio groom is the operational half — run the dry-run below on a
couple of commits and compare. Not yet observed; gated on the run window.
before there's pilot data. The rubric to produce it is below; the decision
itself is a post-observation follow-up (keeping analysis out of a repo doc per
our no-audit-docs norm).
Operator prerequisite (loud, so the pilot is never silently inert)
secrets.ANTHROPIC_API_KEYmust be available to this repo (org- or repo-level) —the finder + verifier agents bill through it. Repo-level secrets here currently
show only
CLOUD_CODE_BOT_PRIVATE_KEY; ifANTHROPIC_API_KEYisn't inheritedfrom the org, provision it before the first scheduled run. Until then the run
fails loudly at the agent step (by design).
How to run the dry-run parity check (feeds AC2/AC3)
Actions → CI - Groom → Run workflow, set dry_run = true. It runs thefull audit + dedup and prints what it would file to the job summary — no
issues opened.
commit: do the CONFIRMED findings overlap in count and substance? Are the
dedup signatures suppressing obvious repeats?
comparable in signal quality to studio groom (few false positives after the
verifier pass), (b) re-running files zero duplicates, and (c) issue volume is
sane (≤
max_findings, default 12). NO-GO / tune if the verifier lets noisethrough or dedup misses re-files — adjust
themes/max_findingson thecaller and re-observe.
Follow-ups (out of scope here — noted for the rollout decision)
bump-groom-callersfleet automation yet (unlike cursor-review/pr-size/agents-md), so the SHA pin is frozen manually. Wiring groom into the
bump-callersmachinery + aGROOM_CALLERSvariable is a rollout-phase task,appropriate once the pilot says GO.
Testing
Single new caller YAML, no backing script — the repo's path-filtered
test-*.ymlsuites don't map to it. Validated:
python3 -c 'yaml.safe_load(...)'parses;with:/secrets:keys cross-checked againstgroom.yml'sworkflow_callcontract; no actionlint/zizmor/pinact gate exists on this repo's own workflows.