chore(sdlc): fleet parity with canonical workflow + action templates - #155
Conversation
Installs the canonical templates this repo was never able to receive: `v1` has pointed at v1.9.0 (2026-08-21) while FuzeSDLC main advanced 92 commits, and governance_sync fetches the canonical AT the pinned ref -- so none of it was even visible, let alone installed. Produced by the canonical installer (scripts/bootstrap/main.py --only workflows) from FuzeSDLC 709de56, the commit v1.10.0 will be cut at (izzywdev/FuzeSDLC#268). Every workflow carries the fuze:managed marker, runs-on is rendered from this repo's declared ci.runner, and .fuze/installed.json records what landed. a2a-maintain.yml is excluded (canonical under active rewrite). Files that differ from the canonical with a local edit or no provenance record are left alone -- --adopt-canonical was not used. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
|
||
| - name: Checkout PR head branch | ||
| if: steps.keys.outputs.present == 'true' | ||
| uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 | ||
| with: | ||
| repository: ${{ github.repository }} | ||
| ref: ${{ github.event.workflow_run.head_branch }} | ||
| fetch-depth: 0 |
fuze-code-review — automated verdictNo verdict was reached — this run is NOT an approval. fuze-code-action conclusion was 'failure', not 'success' — no review was produced, so none can be approved. See the per-rung 'fuze-code-action' notices in the job log for the specific classification (availability / task / declined) and, on an availability failure, the named provider error that triggered it. This is reported as a failed check deliberately: a review that could not run must never be silently indistinguishable from a clean one. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #155 +/- ##
=======================================
Coverage 41.06% 41.06%
=======================================
Files 81 81
Lines 6171 6171
Branches 252 252
=======================================
Hits 2534 2534
Misses 3634 3634
Partials 3 3
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
…t to
harden-gate.yml guards every gate job with
if [ ! -f scripts/gate_X.py ]; then echo "::warning ... skipping"; exit 0; fi
so a MISSING script makes the job report GREEN having never run. Propagating
workflow files alone therefore leaves a repo looking hardened while nothing
executes. This installs, for every gate this repo's own workflows actually
reference, all three parts of the artifact: the job (already present), the
script, and its companion self-test.
The self-tests are not optional -- gate-required-checks HARD-FAILS on a missing
one ("self-tests are missing. They ship with scripts/gate_required_checks.py,
deliberately"), which is why it has been chronically red where the workflow was
present and the test was not.
Two corrections found by running the tests locally before pushing:
* governance/required-checks.json ships WITH gate_required_checks.py. Without
it the self-test raises FileNotFoundError and the gate goes from silently
green to red for a reason that has nothing to do with the repo.
* scripts/__tests__/test_gate_manifest.py is deliberately NOT shipped. Its
CanonicalDeclaresTheCiContract reads governance/repo-manifest.schema.json,
a path a consuming repo must not hold (FuzeSDLC#182/#185 exist to stop a
second schema copy), so it can only ever error. harden-gate's gate-manifest
job does not run it either.
Expect some newly-real gates to fail. A gate that starts failing was always
failing, silently -- not suppressed with continue-on-error or `|| true`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fuze-code-review — automated verdictNo verdict was reached — this run is NOT an approval. fuze-code-action conclusion was 'failure', not 'success' — no review was produced, so none can be approved. See the per-rung 'fuze-code-action' notices in the job log for the specific classification (availability / task / declined) and, on an availability failure, the named provider error that triggered it. This is reported as a failed check deliberately: a review that could not run must never be silently indistinguishable from a clean one. |
| name = repository[len("ghcr.io/"):] | ||
| try: | ||
| tok_url = f"https://ghcr.io/token?scope=repository:{name}:pull&service=ghcr.io" | ||
| with urllib.request.urlopen(tok_url, timeout=timeout) as resp: |
| "application/vnd.docker.distribution.manifest.v2+json", | ||
| ])) | ||
| try: | ||
| with urllib.request.urlopen(req, timeout=timeout) as resp: |
Second commit added: the vacuous-green half
A missing script makes the job report GREEN having never run. So propagating The self-tests are load-bearing, not decoration — Two corrections came out of running the tests locally before pushing:
Newly-real gates are expected to fail on some repos. That is the point: a gate that Why FuzeSDLC#268 has to merge first — now demonstrated, not arguedOn FuzeExecutive#64 the That is the mechanism working exactly as designed — |
Both import `lib.render` from scripts/bootstrap/ -- a package that exists ONLY in
FuzeSDLC. In a consuming repo the repo-local copies cannot import at all:
ModuleNotFoundError: No module named 'lib'
They are also never used. gate-workflow-drift.yml deliberately runs the CANONICAL
copy it just checked out --
python3 .fuzesdlc-canonical/scripts/gate_workflow_drift.py \
--canonical .fuzesdlc-canonical --repo .
-- and never invokes the repo's copy or the test.
Dead weight would be tolerable. It is worse than that: 11 repos' harden-gate.yml
run `unittest discover -s scripts/__tests__ -p 'test_*.py'` -- broad on purpose, so
that every distributed suite fires -- and the unimportable test therefore HARD-FAILS
gate-identifier. Measured on FuzeInfra#771.
caps/workflows.WORKFLOW_DRIFT_SCRIPTS + WORKFLOW_DRIFT_TESTS ship these to every
onboarded repo. That is a canonical defect, reported upstream; this commit stops
this repo carrying a gate it cannot run and that breaks a gate it can.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fuze-code-review — automated verdictNo verdict was reached — this run is NOT an approval. fuze-code-action conclusion was 'failure', not 'success' — no review was produced, so none can be approved. See the per-rung 'fuze-code-action' notices in the job log for the specific classification (availability / task / declined) and, on an availability failure, the named provider error that triggered it. This is reported as a failed check deliberately: a review that could not run must never be silently indistinguishable from a clean one. |
2 participants
What this is
The per-repo half of a fleet-parity sweep against the canonical
workflow-templates/+.github/actions/inizzywdev/FuzeSDLC.Produced by the canonical installer, not by hand:
scripts/bootstrap/main.py --only workflows. Every workflow file carries thefuze:managedmarker,runs-on:is rendered from this repo's declaredci.runnerbylib/render.py(no hand-pinned runner classes), and.fuze/installed.jsonrecords exactly what landed.Root cause (read this first)
This repo is not misconfigured.
governance/versioning.mdsays repos pin themoving
v1alias, andv1has pointed at1585ea1(v1.9.0, 2026-08-21) whileFuzeSDLC
mainadvanced to709de56— 92 commits. Everything below issimply what never got released.
The release request is izzywdev/FuzeSDLC#268 (
baseline-version.txt→1.10.0). Merge that first. This PR installs from709de56, the exactcommit
v1.10.0will be cut at, so once the alias moves the two agreebyte-for-byte and
governance-syncreportsCURRENT.Why this needed a PR at all
governance_sync.pyreconciles.github/actions/**and skills/agents on everyPR — but it reports an absent
.github/workflows/*.ymland deliberatelynever installs one (first-write belongs to
sdlc-bootstrap, which seeds themarker with it). So absent workflow files are the one class the automatic loop
cannot close.
BEFORE → AFTER
Workflow templates that were absent (4)
.github/workflows/fuze-ci-autofix.yml.github/workflows/governance-nightly.yml.github/workflows/telegram-pr-merged.yml.github/workflows/gate-workflow-drift.ymlComposite actions reconciled (0)
none
Gate scripts / self-tests the new workflows shell out to (2)
scripts/gate_workflow_drift.pyscripts/__tests__/test_gate_workflow_drift.pyGovernance policy data (1)
governance/workflow-drift-policy.jsonDeliberately NOT touched
a2a-maintain.yml— the canonical is being rewritten right now; stampingthe current version would distribute a copy that is about to change. Excluded
at the installer level and re-verified against
HEADafter every run.provenance record (
CONFLICT/LOCAL/UNTRACKED). The installer leavesthese alone by default and so does this PR —
--adopt-canonicalwas notused. Resolving them is a separate, reviewable decision:
none
Check state — honest
Self-hosted CI cannot currently run fleet-wide: the ARC
cipool is 2 fixednodes with ~40 runner pods
Pending, and the autoscaler only grows anelasticpool that runner pods cannot select. Expect checks queued/blocked, not
green. Not worked around — switching
runs-on:toubuntu-latestwould be apolicy change, not a fix.
🤖 Generated with Claude Code