zeekayandHanzo Dev
01713cf45b
v3.6.0-.2 could not start. hanzocd-server crash-looped:
fatal: Recovered from panic: nil pointer dereference
server.(*ArgoCDServer).Init -> server/server.go:554
configMapInformer and secretInformer were declared on the struct and Run() in
Init(), but never assigned anywhere in the repo. b2d7140a (delete the
notification subsystem) removed their construction —
secretInformer := k8s.NewSecretInformer(..., "cd-notifications-secret")
configMapInformer := k8s.NewConfigMapInformer(..., "cd-notifications-cm")
— which fed api.NewFactory for notifications and nothing else. The fields and
the two Run() calls survived the deletion, so both were nil at boot.
Deleted rather than reconstructed: they watched notification config, and there
is no notification subsystem to configure. We use hanzoai/notify.
Worth naming the class, because it is the third time tonight: a nil interface
field is valid Go, so `go build ./...` passed clean and said nothing. Same
shape as the Register* seams and the mounted globals — it compiles, and it
yields the zero value.
The "secret key does not exist in secret" warning on the preceding line is
unrelated; hanzocd-secret carries all five keys and works on sha-e1b9244.
Co-authored-by: Hanzo Dev <[email protected]>
Hanzo CD — declarative continuous delivery for Kubernetes
Git holds the desired state; the controller applies it and reports drift.
Hanzo CD is a hard fork of Argo CD (Apache-2.0 — see NOTICE). The engine is theirs. The packaging, API group and platform integration are ours. Their community, docs, support channels and roadmap are not ours, so this file does not borrow them — the previous version of this README was upstream's with the names replaced, which had the effect of putting our name on other people's conference talks and blog posts.
What differs from upstream
| API group | apps.hanzo.ai — Application, ApplicationSet, AppProject |
| annotations | cd.hanzo.ai/* |
| binaries | cd, cd-server, cd-repo-server, cd-application-controller, cd-applicationset-controller, cd-commit-server, cd-cmp-server, cd-dex, cd-git-ask-pass, cd-k8s-auth |
| module | github.com/hanzoai/cd |
| image | ghcr.io/hanzoai/cd |
| SSO | Hanzo IAM (hanzo.id) over OIDC — dex builds but is not deployed |
| notifications | removed; we use hanzoai/notify |
Where it runs
cd.hanzo.ai, namespace hanzo-cd on hanzo-k8s.
It moves git → CR for the fleet; the Hanzo operator keeps CR → workload. The two never write the same field: Hanzo CD owns CR spec from git, the operator owns CR status and the child workload. Disjoint by construction, which is what lets both run without fighting over field ownership.
Deployment layout, the AppProject fences, and the one-observer/three-enforcer
split live in
hanzoai/universe → infra/k8s/hanzo-cd/.
Build
CGO_ENABLED=0 go build ./... # the gate hanzo.yml runs on every PR
Images build on platform.hanzo.ai from the root
Dockerfile; hanzo.yml declares the target.
Releases are tagged. A branch build publishes sha-<short> and will never
advance a service already pinned to a release, so shipping means cutting a
vX.Y.Z tag — not merging to main.