[PR #53] [MERGED] feat(groom): pilot ci-groom.yml caller — groomer-only, dry-run parity dispatch (BE-3873) #63

Closed
opened 2026-10-26 22:35:51 +00:00 by bsakaguchi · 0 comments
Owner

📋 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)

  • 052efdf feat(groom): pilot ci-groom.yml caller — groomer-only, dry-run parity dispatch (BE-3873)
  • 1d97374 fix(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 reusable
groom.yml (landed in #49 / BE-3872), enrolling github-workflows itself as
the first groom pilot repo
(Groom Phase 3, BE-3873).

  • Groomer-only. The reusable finds + files groom-labeled GitHub issues —
    no commits, no PRs, no auto-builder, never merges. Zero prod risk.
  • Schedule: weekly, Mon 09:17 UTC (never on-PR). Plus a workflow_dispatch
    with a dry_run toggle to spot-check parity against a studio groom run on
    the same commit before trusting live filing.
  • Pinned by full commit SHA (07154fb, the merge that added groom.yml +
    the .github/groom/ briefs/ledger) with workflows_ref kept in lock-step, so
    the run always loads the briefs that match the workflow filing them.
  • Files as cloud-code-bot (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: read least-privilege.
  • Volume gate cadence: 7 matches the weekly cron, so a week with nothing
    merged skips the expensive audit.

Why this repo as the pilot (judgment call — Matt, your veto)

The ticket suggests Comfy-Org/comfy-toolbox or another low-risk repo you
pick
. I piloted on github-workflows itself because:

  1. This repo already dogfoods its own reusables (ci-cursor-review.yml,
    ci-detect-unreviewed-merge.yml) — ci-groom.yml is the exact same
    self-enrollment pattern, lowest-friction and lowest-risk.
  2. The one-PR scope of this task lives in this clone; the caller is identical
    whichever repo hosts it.

If you'd rather pilot on comfy-toolbox (it's active and already an
agents-md-integrity caller, so enrolling it is trivial), this same file drops
in 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:

  • ✅ AC1 — working ci-groom.yml caller producing scheduled findings. The
    caller is complete and validated (YAML parses; every with:/secrets: key
    matches groom.yml's declared contract). Findings begin firing once (a) this
    merges to the default branch and (b) the ANTHROPIC_API_KEY prerequisite
    below is satisfied.
  • ⏳ AC2 — findings quality ≈ studio parity; no duplicate re-filing. Dedup
    (no re-filing) is already implemented + unit-tested in the Phase 2 ledger
    (.github/groom/ledger.py, test_ledger.py). The parity observation
    against 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.
  • ⏳ AC3 — go/no-go writeup on expanding to more repos. Can't be written
    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_KEY must 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; if ANTHROPIC_API_KEY isn't inherited
from 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)

  1. Actions → CI - Groom → Run workflow, set dry_run = true. It runs the
    full audit + dedup and prints what it would file to the job summary — no
    issues opened.
  2. Compare that list against what a studio groom run surfaces for the same
    commit: do the CONFIRMED findings overlap in count and substance? Are the
    dedup signatures suppressing obvious repeats?
  3. Go/no-go rubric for expansion: GO if (a) confirmed findings are
    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 noise
    through or dedup misses re-files — adjust themes/max_findings on the
    caller and re-observe.

Follow-ups (out of scope here — noted for the rollout decision)

  • No bump-groom-callers fleet automation yet (unlike cursor-review/pr-size/
    agents-md), so the SHA pin is frozen manually. Wiring groom into the
    bump-callers machinery + a GROOM_CALLERS variable 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-*.yml
suites don't map to it. Validated: python3 -c 'yaml.safe_load(...)' parses;
with:/secrets: keys cross-checked against groom.yml's workflow_call
contract; 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.

## 📋 Pull Request Information **Original PR:** https://github.com/Comfy-Org/github-workflows/pull/53 **Author:** [@mattmillerai](https://github.com/mattmillerai) **Created:** 7/21/2026 **Status:** ✅ Merged **Merged:** 7/21/2026 **Merged by:** [@mattmillerai](https://github.com/mattmillerai) **Base:** `main` ← **Head:** `matt/be-3873-groom-pilot-caller` --- ### 📝 Commits (2) - [`052efdf`](https://github.com/Comfy-Org/github-workflows/commit/052efdff3ac180dbcb67b14b250285973bdcfcdf) feat(groom): pilot ci-groom.yml caller — groomer-only, dry-run parity dispatch (BE-3873) - [`1d97374`](https://github.com/Comfy-Org/github-workflows/commit/1d9737460b081c206f73bcd1c0ec74b08e0249be) fix(groom): drop deadlocking caller concurrency + bypass volume_gate on dry-run (BE-3873) ### 📊 Changes **1 file changed** (+82 additions, -0 deletions) <details> <summary>View changed files</summary> ➕ `.github/workflows/ci-groom.yml` (+82 -0) </details> ### 📄 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 reusable `groom.yml` (landed in #49 / BE-3872), enrolling **`github-workflows` itself as the first groom pilot repo** (Groom Phase 3, BE-3873). - **Groomer-only.** The reusable finds + files `groom`-labeled GitHub issues — no commits, no PRs, no auto-builder, never merges. Zero prod risk. - **Schedule:** weekly, Mon 09:17 UTC (never on-PR). Plus a `workflow_dispatch` with a **`dry_run`** toggle to spot-check parity against a studio groom run on the same commit *before* trusting live filing. - **Pinned by full commit SHA** (`07154fb`, the merge that added `groom.yml` + the `.github/groom/` briefs/ledger) with `workflows_ref` kept in lock-step, so the run always loads the briefs that match the workflow filing them. - **Files as cloud-code-bot** (`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: read` least-privilege. - **Volume gate** `cadence: 7` matches the weekly cron, so a week with nothing merged skips the expensive audit. ## Why this repo as the pilot (judgment call — Matt, your veto) The ticket **suggests `Comfy-Org/comfy-toolbox` or another low-risk repo you pick**. I piloted on **`github-workflows` itself** because: 1. This repo already dogfoods its own reusables (`ci-cursor-review.yml`, `ci-detect-unreviewed-merge.yml`) — `ci-groom.yml` is the exact same self-enrollment pattern, lowest-friction and lowest-risk. 2. The one-PR scope of this task lives in this clone; the caller is identical whichever repo hosts it. If you'd rather pilot on `comfy-toolbox` (it's active and already an `agents-md-integrity` caller, so enrolling it is trivial), this same file drops in 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: - ✅ **AC1 — working `ci-groom.yml` caller producing scheduled findings.** The caller is complete and validated (YAML parses; every `with:`/`secrets:` key matches `groom.yml`'s declared contract). Findings begin firing once (a) this merges to the default branch and (b) the `ANTHROPIC_API_KEY` prerequisite below is satisfied. - ⏳ **AC2 — findings quality ≈ studio parity; no duplicate re-filing.** Dedup (no re-filing) is already implemented + unit-tested in the Phase 2 ledger (`.github/groom/ledger.py`, `test_ledger.py`). The *parity observation* against 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.** - ⏳ **AC3 — go/no-go writeup on expanding to more repos.** Can't be written 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_KEY` must 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`; if `ANTHROPIC_API_KEY` isn't inherited from 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) 1. `Actions → CI - Groom → Run workflow`, set **dry_run = true**. It runs the full audit + dedup and prints what it *would* file to the job summary — no issues opened. 2. Compare that list against what a studio groom run surfaces for the same commit: do the CONFIRMED findings overlap in count and substance? Are the dedup signatures suppressing obvious repeats? 3. **Go/no-go rubric for expansion:** GO if (a) confirmed findings are 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 noise through or dedup misses re-files — adjust `themes`/`max_findings` on the caller and re-observe. ## Follow-ups (out of scope here — noted for the rollout decision) - No `bump-groom-callers` fleet automation yet (unlike cursor-review/pr-size/ agents-md), so the SHA pin is frozen manually. Wiring groom into the `bump-callers` machinery + a `GROOM_CALLERS` variable 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-*.yml` suites don't map to it. Validated: `python3 -c 'yaml.safe_load(...)'` parses; `with:`/`secrets:` keys cross-checked against `groom.yml`'s `workflow_call` contract; no actionlint/zizmor/pinact gate exists on this repo's own workflows. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-26 22:35:51 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Comfy-Org/github-workflows#63
No description provided.