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>
Two homes existed for one job — reconciling KMSSecret CRs into k8s Secrets:
cmd/kms-operator (252 lines) -> ghcr.io/luxfi/kms-operator
hanzoai/kms-operator (own repo) -> ghcr.io/hanzoai/kms-operator
hanzoai/kms-operator is the one that actually runs, on BOTH clusters
(lux-k8s kms-operator-system/kms-operator-controller-manager and hanzo-k8s
kms-operator-canonical). This repo's own docs already say so:
internal/documents/architecture.md calls hanzoai/kms-operator canonical and the
luxfi name "older"; index.md flags the remaining luxfi pins as drift. The only
thing still pinning ghcr.io/luxfi/kms-operator is lux-devnet/kms-zap-operator,
scaled 0/0.
So this was the dead duplicate. Delete it rather than keep fixing it — I had
just repaired its vendor drift in v1.12.8, which fixed a build for a component
that should not exist. Deleting beats fixing a second way to do one thing.
Also drop NOTICE. It carried the MIT attribution for Infisical-derived code —
required while that code was present, and it was: the vendored Infisical
console. a6a933d removed it. Nothing derived remains (0 TS/JS files, 0
Infisical references across all 60 Go files), so the attribution no longer
applies. The empty frontend/ directories go too.
The KMS service itself is untouched: cmd/kms builds and pkg/keys + cmd/kms
tests pass.
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>
a6a933d ("kms is the Go service on /v1/kms — delete the Infisical console")
removed Dockerfile.server and Dockerfile.web but left .github/workflows/
untouched. build-server-self.yml still passes `file: Dockerfile.server`, so
every run since fails immediately:
ERROR: failed to solve: failed to read dockerfile:
open Dockerfile.server: no such file or directory
Delete the workflow rather than repoint it. It existed to build a second,
"self-contained" variant of the same server into ghcr.io/luxfi/kms:server —
a duplicate path for one job. The main Dockerfile (Build KMS) already builds
the server, and the :server image is consumed by nothing: zero pods reference
it on either lux-k8s or hanzo-k8s, and the only remaining mentions are this
workflow and a historical note in hanzo/kms/DEPRECATED.md.
Leaves one Dockerfile and one server build.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
Replace all inline references to the legacy upstream project with Lux KMS
branding (prose/labels), neutral identifiers (code), and neutral string
literals (frontend-internal cache keys, sentinels, masks), with every
reference renamed consistently so behavior is unchanged. Dead networking
UI (relay/gateway/pam) CLI examples now reference the Lux CLI.
Add a NOTICE file carrying the required upstream MIT attribution and full
permission notice — the only place the upstream name remains, as required
by that license.
No functional changes. Frontend (vite build) and Go backend
(go build -tags sqlite_fts5 sqlcipher) both build green.
runs-on [self-hosted,linux,amd64] never matches the lux-build ARC
AutoscalingRunnerSet (its runner label is the scale-set name 'lux-build'),
so Build KMS jobs queued forever with 'assigned job=0'. Same fix already
applied to build-operator.yml.
zapclient imports github.com/luxfi/kms/pkg/{envelope,zap}, which are the
module's own packages. -mod=vendor only vendors external deps, so these
must be present in the Docker build context as source. The selective COPY
missed them, so the build failed:
pkg/zapclient/client.go:34:2: cannot find module providing package
github.com/luxfi/kms/pkg/envelope: import lookup disabled by -mod=vendor
COPY both packages; also add them to the workflow paths filter so the
operator image rebuilds when they change.
The deployed kms-operator (ghcr.io/luxfi/kms-operator:0d446b0) is the legacy
Infisical-flavor HTTP operator: it POSTs /api/v1/auth/universal-auth/login,
which the Go KMS server does NOT expose, so every KMSSecret sync fails with
CallUniversalAuthLogin 404 (e.g. lux-devnet/luxd-staking-kms-sync). The fix —
cmd/kms-operator, which reconciles over the native luxfi/zap binary transport
on port 9999 (no HTTP auth round-trip) — already exists in source but had no
CI to ship it. Add a self-contained build for Dockerfile.operator (same
pattern as build-lux-kms.yml), publishing ghcr.io/luxfi/kms-operator.
Replaces non-canonical scale-set / org-prefixed labels with the
existing labels every arcd host registers with. Matches evo for
amd64 and spark for arm64. No new labels added.
Squashes all pre-rewrite history into a single root commit. Previous tree:
- 14506 commits including upstream Infisical fork history
- Multiple merge chains carrying pre-purge content
Force-rewrite per disk-space reclamation discipline. GHCR images
(1.9.9, 1.9.11) remain immutable; their git lineage is no longer
materialized.
z