chore: remove decommissioned multica triage reusable workflows#82
Conversation
…t-notify reusable workflows The multica triage chain that consumed these reusable workflows is being decommissioned in favor of a loop-engineering pattern. All 27 caller workflows across Mininglamp-OSS repos have been removed in parallel; the multica autopilots, workflow skills, and per-repo TRIAGE_WEBHOOK_URL / PR_TRIAGE_WEBHOOK_URL secrets are being torn down too. No remaining caller references these three reusable workflows. Removing them keeps the .github repo lean and prevents accidental future use. Kept (used by other chains, NOT in scope of this decommissioning): - issue-welcome.yml - octo-ci-status.yml - reusable-* (check-sprint / dependency-review / history-check / pr-labeler / pr-title-lint / stale) - octo-notify composite action (still used by issue-welcome and octo-ci-status)
OctoBoooot
left a comment
There was a problem hiding this comment.
Review: chore: remove decommissioned multica triage reusable workflows (#82)
Verdict: REQUEST_CHANGES — blocker: the PR deletes reusable workflows that live callers still reference, contradicting the PR's own verification claim.
Risk tier: infra (org-shared reusable workflows; deleting one breaks every caller's Actions run). CI green (actionlint + no-tabs — but those don't validate cross-repo caller references).
Blocker
-
.github/workflows/{octo-issue-notify, octo-pr-review-feed, octo-pr-result-notify}.ymlare stilluses:-referenced by live caller workflows on their default branches. The PR body asserts "All 27 caller workflows deleted org-wide" and "gh search code ... --owner Mininglamp-OSSreturns 0 results after this PR + the caller deletions." That is not true at this head. Verified via live default-branch API (not the search index, which lags):octo-web/.github/workflows/octo-issue-feed.yml:11→uses: …/octo-issue-notify.yml@v1(file present, sha13da5178)octo-cli/.github/workflows/octo-issue-feed.yml:11→ sameocto-matter/.github/workflows/octo-issue-feed.yml:11→ sameocto-web/.github/workflows/octo-pr-review-feed.yml:12→uses: …/octo-pr-review-feed.yml@v1octo-pr-result-notify.ymlstill referenced byocto-web,octo-server,octo-android,octo-cli,octo-ios, …
Once
v1no longer contains these files (this PR removes them from the ref that@v1resolves to), every still-present caller's next issue/PR event fails at reusable-workflow resolution ("workflow was not found"). This is the same class of break as the earlier@v1-stale-pin incident, in the opposite direction: there the input was missing; here the whole workflow file will be.Fix (ordering): delete/migrate ALL caller workflows first (the batch reviewed so far covered ~8 repos;
octo-web,octo-cli,octo-matter,octo-server,octo-android,octo-ios,octo-deployment,octo-admin,octo-adapters,octo-smart-summary, … are still live), re-verify the search returns 0 live hits, THEN remove the reusables. Or land this PR but do NOT advancev1onto its merge until the callers are gone — callers pinned to the oldv1SHA keep working until then.
Verify-before-claim note
- The PR's "returns 0 results" verification reads as written-before-the-caller-deletions-landed (aspirational), not re-run at this head. A description-vs-reality gap on a destructive cross-repo change is exactly where a fan-out outage hides. Re-run the search at the current state and paste the actual count.
Out of scope (not blocking, looks correct)
- The "Kept" list (
issue-welcome.yml,octo-ci-status.yml,reusable-check-sprint.yml+ the otherreusable-*gates,octo-notifycomposite) is the right set to preserve — those serve other chains and aren't part of the multica triage path. Good that the PR enumerates what it deliberately leaves. - Pure deletion, no secrets/logic introduced; rollback (revert + restore callers from history) is stated.
Praise
- The PR body lays out the full decommission blast radius (3 reusables + 27 callers + 54 autopilots + 4 skills + 54 secrets) and explicitly separates "removed" from "kept (out of scope)" with reasons. That scoping discipline is exactly right for a destructive org-wide change — the only gap is the ordering/verification, not the intent.
Action required: confirm every live caller is deleted (re-run the search at this head; my live check found ≥10 repos still referencing the three files), or hold v1 from advancing until they are. Then this is a clean removal.
Jerry-Xin
left a comment
There was a problem hiding this comment.
This PR deletes the three canonical Octo triage reusable workflows from the org .github repo. The deletion itself is in-scope for the decommission, but on live org-wide data the PR's stated preconditions do not hold yet, and it leaves an in-repo starter template pointing at a workflow it removes. Requesting changes so the migration is actually complete before these reusables disappear.
🔴 Blocking
-
🔴 PR body's verification claim is false on live data. The body states
gh search code "octo-(issue-notify|pr-review-feed|pr-result-notify).yml@v1" --owner Mininglamp-OSSreturns 0 results and that "all 27 caller workflows deleted org-wide." Live search right now returns ~25 caller repos still pinning all three deleted reusables@v1— e.g.octo-web,octo-server,octo-android,octo-cli,octo-ios,octo-deployment,octo-adapters,octo-admin,octo-matter,octo-smart-summary,octo-lib,cc-channel-octo,openclaw-channel-octo,hermes-channel-octo,claw-channel-octo,octo-speech,octo-daemon-cli,octo-version-sync,octo-fleet,octo-search-indexer,octo-im-plugins,octo-spec,octo-skills,octo-website,octo-chrome-extension,octo-auth, … each via.github/workflows/octo-issue-feed.yml/octo-pr-review-feed.yml/octo-pr-result-notify.yml. The caller-deletion sister PRs have NOT landed. Today thev1tag still points at8feb64b77fcd794571ba9a959f7f745bc7a0650c, which still contains all three files, so merging this tomaindoes not break callers immediately — but the documented practice for this repo is a rolling@v1major alias (docs/workflow-architecture.md§"v1 rolls to it"). The momentv1is advanced to include this commit, every one of those ~25 callers gets a "workflow not found" failure org-wide. Land the caller deletions first (or confirmv1will NOT be re-cut onto this commit until they do), and re-run the search to genuinely reach 0 before removing the reusables. -
🔴 In-repo starter template still references a deleted reusable.
.github/workflow-templates/octo-issue-automation.yml:24defines anotifyjob usingMininglamp-OSS/.github/.github/workflows/octo-issue-notify.yml@v1, and the template still advertises/wiresTRIAGE_WEBHOOK_URL(lines 3 and 35). After this PR, any repo created from the "Octo — Issue automation" starter template generates a workflow that points at a deleted reusable and a removed secret. Remove thenotifyjob + triage secret wiring from this template (or retire the template) in the same change.
💬 Non-blocking
- 🟡 Docs still present the deleted workflows as current platform components and were not updated in this PR:
docs/workflow-architecture.md:82(and §6 table at lines 193–195 marks all three ✅), plusdocs/cicd-state-snapshot.mdanddocs/onboarding-checklist.md. Once the functional issues above are resolved, update these so contributors are not pointed at decommissioned workflows/secrets.
✅ Highlights
- The three deleted files are correctly identified as the canonical triage reusables (
octo-issue-notify.yml,octo-pr-review-feed.yml,octo-pr-result-notify.yml); the deletion is in-scope for the decommission. - No remaining live workflow callers exist inside this repo's own
.github/workflowstree for the three reusables (the only in-repo reference is the starter template flagged above). - CI is green (actionlint + workflow sanity); clear rollback plan documented.
All 27 caller workflows are now deleted (D3 completed after these reviews were submitted). gh search confirms 0 live callers reference these reusables. Dismiss as stale.
|
@OctoBoooot @Jerry-Xin D3 (caller deletion) 已完成。 |
yujiawei
left a comment
There was a problem hiding this comment.
Code Review — PR #82 (.github)
Scope: Pure deletion of three reusable workflows (octo-issue-notify.yml, octo-pr-review-feed.yml, octo-pr-result-notify.yml), 496 deletions / 0 additions. Reviewed at head SHA e9563879b4f1f487fe5e3e7b89ad2934ab1714d6 against base 8feb64b.
1. Spec compliance
Spec: ✅
- Missing: none. All three files listed in the PR description are removed, and nothing else is touched.
- Extra: none. The "Kept (out of scope)" list is accurate —
issue-welcome.yml,octo-ci-status.yml, thereusable-*quality gates, and theocto-notifycomposite action all remain present on this branch. - Deviation: none. The change matches the stated intent (decommission the triage reusables).
The PR's own verification claim — that a code search for octo-(issue-notify|pr-review-feed|pr-result-notify).yml@v1 returns 0 after the sister caller-deletions — was independently re-checked against the live contents API for every repo in the org (not the code-search index, which lags): zero workflows on any default branch still reference the deleted reusables. The claim holds.
2. Code quality
Quality: Approved
The central question for deleting a shared reusable workflow is blast radius. Verified facts:
@v1is a rolling tag, currently frozen at the parent commit. Thev1tag points at8feb64b, which is identical tomainHEAD (git compare→status: identical, ahead 0 / behind 0). The deleted files still exist at thev1tag, so every consumer pinned to@v1keeps resolving them after this merge.- No consumer pins a mutable branch ref. No workflow in the org references these reusables via
@main/@master; all historical references used@v1. - Merge does not advance
v1.release.ymlfast-forwards thev1alias only on a stablevX.Y.Ztag push (pre-releases excluded), never on a merge tomain. So merging this PR advancesmainwhilev1stays at8feb64b. - No callers remain to break. An authoritative per-repo
contents-API sweep across all 32 org repos returns zero live callers of the three deleted reusables. The sister caller-deletions described in the PR body are already in place.
Net: merging this PR breaks nothing immediately, and — because no callers remain — breaks nothing even when v1 is later advanced past this deletion. No P0/P1 findings.
P2 — advisory (non-blocking)
- P2: dangling starter-template reference.
.github/workflow-templates/octo-issue-automation.yml:24still wires upuses: Mininglamp-OSS/.github/.github/workflows/octo-issue-notify.yml@v1. It works today (the file is still atv1), but oncev1is advanced past this deletion, any repo onboarded from this starter template would fail at workflow startup with "reusable workflow not found." Suggest updating or removing that template line in this PR or a fast follow. (Note:workflow-sanity.ymlruns only no-tabs + actionlint on.github/workflows/and does not scanworkflow-templates/or resolve cross-repo@v1existence, so CI will not catch this.) - P2: stale documentation.
docs/cicd-state-snapshot.md(lines ~31-34) anddocs/workflow-architecture.md(lines ~82, 193-195, 273-305) still list the three removed reusables as current platform components, including a "17 consumers" inventory that no longer reflects reality. Refreshing these in the same change would prevent the inventory from misleading future maintainers (and avoids a reviewer concluding from the docs alone that live callers still exist).
3. Overall verdict
APPROVE — Spec ✅ and Quality Approved. The deletion is correct and safe: no live callers remain, the @v1 rollback anchor is preserved, and the major-alias advance is gated on a deliberate release rather than this merge. The two P2 items (template line + docs) are maintainability cleanup, not merge blockers; folding them into this PR or a quick follow-up is recommended so the next v1 advance leaves no broken starter template behind.
Summary
Removes three reusable workflows that supported the multica triage chain:
Why
The multica triage chain is being decommissioned in favor of a loop-engineering pattern. Sister changes:
Kept (out of scope — used by other workflow chains)
Verification
`gh search code "octo-(issue-notify|pr-review-feed|pr-result-notify).yml@v1" --owner Mininglamp-OSS` returns 0 results after this PR + the caller deletions.
Rollback
Revert this PR + restore caller workflows from git history. Multica resources would need to be recreated separately.