299b230 deleted this in favour of platform.hanzo.ai native builds (hanzo.yml).
The native plane does not serve yet — the platform Deployment is scaled to 0/0
and PLATFORM_BUILD_CALLBACK_TOKEN, the bearer POST /v1/runner requires, is in
neither cluster — so the cutover left kms the one repo in the fleet that could
not build at all, while every sibling kept building on Actions (luxfi/node has
19 active workflows, hanzoai/gateway 3, hanzoai/commerce 1).
The 422 that motivated the cutover, "Actions has been disabled for this user",
is account-scoped rather than repo-scoped: hanzo-dev gets it, zeekay does not.
Push-triggered runs separately stopped firing around 2026-07-24, so builds want
an explicit dispatch regardless.
hanzo.yml stays and now says plainly that it is intent, not the live path. Cut
over when the native plane serves, and fleet-wide rather than one repo at a time.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
GitHub answers a workflow dispatch on this repo with 422 "Actions has been
disabled for this user", so pushes to main produced no build at all — the last
run is still the commit before the console removal, and the deployed image
drifted behind main without anything reporting a failure.
hanzo.yml hands the build to platform.hanzo.ai, which schedules it onto the
self-hosted arcd pools over the native fabric and pushes to GHCR. Same path
luxfi/node uses. .github/workflows/build-lux-kms.yml is retired rather than
left as a second, broken way to produce the same image.
No deploy block: the kms Deployment is kustomize-managed with no operator CR,
so there is nothing for a Service-CR rollout to target.
VERSION 1.12.6 -> 1.12.8. The file had fallen behind the deployed tag v1.12.7,
so a tag build would have gone backwards.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
