mirror of
https://github.com/Comfy-Org/github-workflows.git
synced 2026-11-05 00:17:37 +00:00
[PR #53] [MERGED] feat(groom): pilot ci-groom.yml caller — groomer-only, dry-run parity dispatch (BE-3873) #63
Labels
No labels
cursor-review-catalog-drift
groom
groom
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Comfy-Org/github-workflows#63
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/Comfy-Org/github-workflows/pull/53
Author: @mattmillerai
Created: 7/21/2026
Status: ✅ Merged
Merged: 7/21/2026
Merged by: @mattmillerai
Base:
main← Head:matt/be-3873-groom-pilot-caller📝 Commits (2)
052efdffeat(groom): pilot ci-groom.yml caller — groomer-only, dry-run parity dispatch (BE-3873)1d97374fix(groom): drop deadlocking caller concurrency + bypass volume_gate on dry-run (BE-3873)📊 Changes
1 file changed (+82 additions, -0 deletions)
View changed files
➕
.github/workflows/ci-groom.yml(+82 -0)📄 Description
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.
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.