[PR #148] [MERGED] chore(ci): unenroll this repo from its own unreviewed-merge detector #157

New issue

Closed

opened 2026-10-26 22:36:52 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-26 22:36:52 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/Comfy-Org/github-workflows/pull/148
Author: @mattmillerai
Created: 8/11/2026
Status: ✅ Merged
Merged: 8/11/2026
Merged by: @mattmillerai

Base: main ← Head: matt/disable-self-unreviewed-merge

📝 Commits (1)

128a211 chore(ci): unenroll this repo from its own unreviewed-merge detector

📊 Changes

5 files changed (+9 additions, -39 deletions)

View changed files

📝 .github/reviewers.yml (+2 -3)
📝 .github/workflows/ci-assign-reviewers.yml (+1 -1)
➖ .github/workflows/ci-detect-unreviewed-merge.yml (+0 -32)
📝 .github/workflows/ci-groom.yml (+1 -1)
📝 AGENTS.md (+5 -2)

📄 Description

What

Deletes .github/workflows/ci-detect-unreviewed-merge.yml — the caller that enrolled this repo in its own SOC 2 unreviewed-merge detector, opening a tracking issue in Comfy-Org/unreviewed-merges on every push to main here.

Only this repo's own caller. The reusable detect-unreviewed-merge.yml, its docs, and its bump fleet are untouched — every consumer stays enrolled and unaffected.

ELI5

We have a workflow that notices "this PR got merged without anyone approving it" and files a compliance ticket. We had it pointed at this repo too. But merging something here doesn't change anything anywhere by itself: consumers pin us by commit SHA, so a change only reaches them through a bump PR that they review and approve — and their own detector watches that merge. So the check was firing one step upstream of where the change actually takes effect, on a repo whose merges ship nothing on their own.

Why this isn't a control gap


Does a merge here deploy anything?	No. Consumers pin by full commit SHA.
How does a change reach a consumer?	A SHA-bump PR opened in that consumer repo.
Who approves that?	That repo's reviewers, under that repo's branch protection.
Who audits that merge?	That repo's own `detect-unreviewed-merge` caller.

The detective control still applies at the point where the change actually takes effect. This removes a duplicate that audited an intermediate step.

Also cleaned up (dangling references to the deleted file)

.github/reviewers.yml — routing entry for the removed path.
ci-groom.yml / ci-assign-reviewers.yml — header comments that cited it as a sibling self-enrollment caller.
AGENTS.md — its self-enrollment-callers list, plus a note recording the non-enrollment as deliberate, so a future audit ("this repo should self-enroll like it does for cursor-review") doesn't silently re-add it.

Verification

python3 .github/agents-md-integrity/check_agents_md.py --root . → passed (2 pre-existing warnings: 189/150 aspirational line target, no CODEOWNERS — both present before this change, ceiling is 200).
python3 -m unittest discover -s .github/refresh-reviewers/tests → 48 passed.
YAML parse-check on all three edited workflow/config files → OK.
grep -rn ci-detect-unreviewed-merge . → only the intentional "do not re-add" line in AGENTS.md.

Reverting

Restore the deleted file (it pinned detect-unreviewed-merge.yml@4d9cb6b) and its reviewers.yml entry. secrets.UNREVIEWED_MERGES_TOKEN is untouched, so re-enrollment needs no re-provisioning.

Provenance

Requested by @mattmillerai — rationale in "Why this isn't a control gap" above is theirs.

🤖 Generated with Claude Code

_{🔄 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/148 **Author:** [@mattmillerai](https://github.com/mattmillerai) **Created:** 8/11/2026 **Status:** ✅ Merged **Merged:** 8/11/2026 **Merged by:** [@mattmillerai](https://github.com/mattmillerai) **Base:** `main` ← **Head:** `matt/disable-self-unreviewed-merge` --- ### 📝 Commits (1) - [`128a211`](https://github.com/Comfy-Org/github-workflows/commit/128a211166a46d148fba2fbb626deb45e3b43602) chore(ci): unenroll this repo from its own unreviewed-merge detector ### 📊 Changes **5 files changed** (+9 additions, -39 deletions) <details> <summary>View changed files</summary> 📝 `.github/reviewers.yml` (+2 -3) 📝 `.github/workflows/ci-assign-reviewers.yml` (+1 -1) ➖ `.github/workflows/ci-detect-unreviewed-merge.yml` (+0 -32) 📝 `.github/workflows/ci-groom.yml` (+1 -1) 📝 `AGENTS.md` (+5 -2) </details> ### 📄 Description ## What Deletes `.github/workflows/ci-detect-unreviewed-merge.yml` — the caller that enrolled **this** repo in its own SOC 2 unreviewed-merge detector, opening a tracking issue in `Comfy-Org/unreviewed-merges` on every push to `main` here. **Only this repo's own caller.** The reusable `detect-unreviewed-merge.yml`, its docs, and its bump fleet are untouched — every consumer stays enrolled and unaffected. ## ELI5 We have a workflow that notices "this PR got merged without anyone approving it" and files a compliance ticket. We had it pointed at this repo too. But merging something here doesn't change anything anywhere by itself: consumers pin us by commit SHA, so a change only reaches them through a bump PR that *they* review and approve — and their own detector watches that merge. So the check was firing one step upstream of where the change actually takes effect, on a repo whose merges ship nothing on their own. ## Why this isn't a control gap | | | |---|---| | Does a merge here deploy anything? | No. Consumers pin by full commit SHA. | | How does a change reach a consumer? | A SHA-bump PR opened in that consumer repo. | | Who approves that? | That repo's reviewers, under that repo's branch protection. | | Who audits that merge? | That repo's own `detect-unreviewed-merge` caller. | The detective control still applies at the point where the change actually takes effect. This removes a duplicate that audited an intermediate step. ## Also cleaned up (dangling references to the deleted file) - `.github/reviewers.yml` — routing entry for the removed path. - `ci-groom.yml` / `ci-assign-reviewers.yml` — header comments that cited it as a sibling self-enrollment caller. - `AGENTS.md` — its self-enrollment-callers list, plus a note recording the non-enrollment as **deliberate**, so a future audit ("this repo should self-enroll like it does for cursor-review") doesn't silently re-add it. ## Verification - `python3 .github/agents-md-integrity/check_agents_md.py --root .` → passed (2 pre-existing warnings: 189/150 aspirational line target, no CODEOWNERS — both present before this change, ceiling is 200). - `python3 -m unittest discover -s .github/refresh-reviewers/tests` → 48 passed. - YAML parse-check on all three edited workflow/config files → OK. - `grep -rn ci-detect-unreviewed-merge .` → only the intentional "do not re-add" line in AGENTS.md. ## Reverting Restore the deleted file (it pinned `detect-unreviewed-merge.yml@4d9cb6b`) and its `reviewers.yml` entry. `secrets.UNREVIEWED_MERGES_TOKEN` is untouched, so re-enrollment needs no re-provisioning. ## Provenance Requested by @mattmillerai — rationale in "Why this isn't a control gap" above is theirs. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-26 22:36:52 +00:00