The Go port took 24 entries from a Python dict that held 40. Sixteen repos were
in NEITHER sync leg afterwards -- not pull mirrors, so nothing brought them in,
and absent from this table, so nothing pushed them forward -- which is the exact
shape the port was written to eliminate, reintroduced by the port itself.
The worst of them is hanzoai/ci. Every repo in three orgs imports it as
`hanzoai/ci/...@v1`, and a stale pipeline runs GREEN, so a caller cannot tell a
current pipeline from one months old. It had already sat 18 commits behind once
for exactly this reason. The rest: console and namespace (shipping services whose
inbound leg was never written down), the five hanzo-apps surfaces, hanzo-go/sdk
and hanzo-rs/sdk (published SDKs that `go get` and `cargo` resolve against the
forge copy -- 16 and 10 commits behind when they were found), hanzo-dart,
hanzokv, hanzozt, hanzo-docs/team and luxfi/aml.
Two guards, because a table that quietly loses rows is not a thing to notice
twice. One asserts every declared org is in the allowlist -- without it an entry
in a new org is refused and the only symptom is a smaller "N of M resolved". The
other asserts the count and names five of the entries that went missing.
The allowlist gains hanzo-inc, and the live run is why. Three declared repos --
auto, blog and visor -- have been transferred there, and the run refused all
three by name rather than pushing into an org nobody had listed. That is the
guard working: it is an allowlist so that an unknown org is a question, not an
assumption. hanzo-inc is ours (created 2026-07-24, all three private and pushed
within the week), so it is listed now and the refusal goes away.
Measured against live GitHub: 40 of 40 resolve, exit 0. EIGHT only resolve
because names are RESOLVED and never matched against a listing -- three moved to
hanzo-apps, three to hanzo-inc, esign became sign, kms-v1 became kms. A listing
would have reported eight absences, and an absent name raises nothing.
Co-authored-by: Hanzo Dev <[email protected]>
Reconcile could never have worked. RealGit set no working directory, so every
command ran wherever the process started — for a scheduled job, nowhere — and git
answers "fatal: not a git repository" to the fetch. That error arrives on the
branch that reports GITHUB as unreadable, so a reconciler with perfect
credentials and a perfect table would have called all 24 repos unreachable and
asked a person to look at each one. The dry run passed throughout, because a dry
run resolves names and never touches git.
Git therefore takes the directory as a parameter, and Workspace prepares one
store per repo under a root that MAY survive between runs. May, not must: git's
fetch negotiation offers whatever is already present, so a kept root makes later
runs deltas, and an empty one is equally correct and merely slower. That is what
lets the job use an emptyDir instead of a claim — a ReadWriteOnce volume would
buy the same time at the price of a job pod deadlocking on Multi-Attach whenever
it schedules away from the node holding it.
Both sides are now fetched, not just GitHub. The forge goes first for two
reasons: its tip has to be local before a genuine divergence can be NAMED rather
than reported as "ancestry undetermined", and once its history is present those
objects are offered in negotiation, so the internet side of every run is a delta
even on an empty store. That is the whole reason ten-minute scheduling is
affordable over two dozen repositories.
The proof is a real one. TestFastForwardMovesARealRepository builds two bare
repositories, leaves the forge a commit behind, and requires it to end on
GitHub's tip — then rewinds GitHub so the two genuinely disagree and requires the
forge NOT to move. Every other test in this file uses a fake that agrees with the
code about what git is, which is exactly why none of them caught this. Verified
by mutation: drop `cmd.Dir` and it fails.
Shipping is one binary, not two. cmd/hanzo-mirror becomes cmd/cd-mirror,
dispatched by argv[0] like every other cd command, so the reconciler travels in
the image the control plane already builds, pins and deploys — no second artifact
to version, and no second chance for the two to disagree about which repos exist.
The table travels with it at common.DefaultMirrorTable rather than living in a
ConfigMap, so the JSON that CI validates is the JSON the scheduled run reads.
Co-authored-by: Hanzo Dev <[email protected]>
I pushed a build break to main and this is the fix.
The import said github.com/hanzoai/deploy/mirror, which was correct when I wrote
it: go.mod read `module github.com/hanzoai/deploy`. Another session renamed the
module to github.com/hanzoai/cd, my rebase picked that up, and the import went
stale in the same operation that made it stale -- so `go build ./mirror/
./cmd/hanzo-mirror/` passed before the rebase and `go build ./...` failed after.
Worth naming because the failure mode is not obvious: a wrong INTERNAL import
does not read as a typo, it reads as a missing dependency --
"cannot find module providing package ... import lookup disabled by -mod=readonly"
-- which sends you looking for a go.mod require line that was never the problem.
Checked the whole module, not just the two packages I touched: go build ./...
is clean.
Co-authored-by: Hanzo Dev <[email protected]>
Replaces hanzoai/mirrors' reconcile.py + sync.py. The port is not a translation:
each thing it does differently is a bug the Python had, and every one of those
bugs failed SILENTLY.
Names are RESOLVED, never matched against a listing. Resolve and List are
separate methods so a call site has to choose. GET /repos/{org}/{name} follows a
rename and a transfer permanently; a listing reports a repo only under its
current name in its current org, so six entries whose repos had moved were never
visited once -- and nothing failed, because an absent name raises nothing. The
dry run against live GitHub now prints all five drifted repos by name:
hanzoai/sign <- hanzoai/esign
hanzoai/kms <- hanzoai/kms-v1
hanzoai/hanzo.{sh,one,network} <- hanzo-apps/*
The table is CONFIG (mirror/repos.json), not a list literal in source. Adding
hanzo-ai/cloud hours ago was a code edit, which is not what declared state means
-- and until then cloud was in NEITHER leg: is_mirror=0 so nothing pulled in,
absent from the table so nothing pushed in. Its CI ran on a commit four behind
for a day while merely looking red. All 24 entries carry over, cloud and crawl
included.
Direction is ONE typed value with one meaning. In the Python `mirror` meant both
a vestigial git config flag and the forge's actual push refspecs, and reading the
wrong one produced a confident wrong answer about whether a push could delete
history.
FAST-FORWARD IS GIT'S GUARANTEE, NOT THIS PROGRAM'S: the refspec carries no
leading '+'. A check written in Go could be reasoned around by a later edit; a
missing '+' cannot. TestFastForwardNeverForces asserts on the ARGUMENT rather
than the outcome, so it fails if anyone ever adds one. A push mirror once pruned
the v1.0-v1.31 tag range off an IAM repo and the objects were then collected.
Divergence is reported and left alone, and exits non-zero. Two people disagreeing
about history is a question for a person; a sync job that settles it destroys
whichever side lost.
Fails CLOSED on an absent credential instead of proceeding unauthenticated. An
empty token yields a 401 that reads like a permissions problem -- the exact shape
that hid a broken npm publish for weeks, every request unauthenticated because a
name resolved to "" and nothing said so. Same for a table entry with no
direction: that field decides which side may overwrite the other, so there is no
safe default.
Git is injectable, so the fast-forward decision is tested without a network. A
safety property that can only be exercised against live remotes is one nobody
exercises. 7 tests, all passing; build and vet clean.
Not yet wired to a schedule, and reconcile.py still runs -- deleting it before
this replaces it would leave a window with neither.
Co-authored-by: Hanzo Dev <[email protected]>
House rule: /v1/ is the API prefix, everywhere, and /api/ is never added on
top of it. The api.* subdomain names the API; a path prefix restating it is
noise. This applies it to the whole route surface:
/api/v1/* -> /v1/* 106 proto annotations, 109 gateway patterns
/api/version -> /v1/version
/api/badge -> /v1/badge
/api/webhook -> /v1/webhook (server + applicationset controller)
/api/dex/* -> /v1/dex/* (constants; dex is built, not deployed)
The grpc-gateway .pb.gw.go files are generated, and the plugin toolchain is
not on this machine, so they were rewritten by a script that applies exactly
the transform codegen would: for /api/v1 paths, drop the leading "api"
literal-push opcode pair and decrement every LitPush(2,N)/Capture(5,N) pool
index; for /api/version, rename the segment. ConcatN(4,N) operands are
counts, not pool indexes, and are untouched. The .proto annotations moved in
the same commit, so the next real codegen run is a no-op against these files.
MustPattern panics at package init on a malformed pattern, so every rewritten
pattern is validated by any import of pkg/apiclient — those tests pass.
Also moved: assets/swagger.json (82 paths), the UI's two roots (apiRoot()
'/v1', version-service '/v1/version') and its two relative composers (app
logs download, badge panel), the five audit-pattern regexes in server.go, and
the tests that asserted the old paths. terminal_test's request URL claimed
/api/v1/terminal, a route that never existed — the handler is mounted at
/terminal; the fixture now says so.
NOT touched, deliberately: /api/v3 in GitHub Enterprise base-url examples
(GitHub's URL shape, not ours), util/vendored/kubeclientmetrics (parses the
KUBERNETES API server's /api/v1 paths), and util/http's cookie-path fixture
(arbitrary string exercising slash normalization).
go build ./... clean. Pre-existing failures in badge/session/webhook/account
tests reproduce identically on the parent commit (rebrand fallout — badge
colors, cookie name length, dex issuer) and are not made worse here.
External consumers checked: universe has zero references to cd.hanzo.ai/api;
the CLI speaks gRPC, not the REST gateway; UI and server ship in one image so
they move together.
Co-authored-by: Hanzo Dev <[email protected]>
go.mod still declared `module github.com/hanzoai/deploy` after the repo was
renamed. A Go module path is not cosmetic — it is the resolvable location. So
`go get github.com/hanzoai/cd` could not work, and anything importing this
module had to spell a name that no longer exists at that address. The build log
of v3.6.0 is where it surfaced: the compiler was still emitting
github.com/hanzoai/deploy/cmd/cd/commands.
3541 import paths across 690 .go, 19 .proto, 4 .yaml, 3 .sh, 2 .mod, Procfile
and Makefile. Plus the 62 ghcr.io/hanzoai/deploy image references, moved to
ghcr.io/hanzoai/cd to match hanzo.yml's build target — a distinct string from
the module path, replaced separately so neither could clobber the other.
go mod tidy clean, CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build ./... clean.
Co-authored-by: Hanzo Dev <[email protected]>
Two corrections on top of the naming pass, both found by checking the live
cluster rather than the source.
The rename had silently changed the user-facing annotation key from
argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live
Applications carry the old key, so deploying that would have ignored every
sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*,
and universe 575650286 moves the ApplicationSet template that stamps it, so
the controller regenerates all 63 consistently.
The API group in code said argoproj.io/v1alpha1 in 157 places while the
cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are
applications.apps.hanzo.ai). Code now matches what is actually served.
The legacy applications.argoproj.io/app-name label had ZERO live users, so it
went with the rest. foo.argoproj.io test fixtures became foo.example.com —
arbitrary test domains should not carry a vendor name.
go build ./... exit 0.
Co-authored-by: Hanzo Dev <[email protected]>
The last argoproj dependency. notifications-engine was 49 files / 920K and
backed a subsystem with ZERO live workloads and ZERO Applications carrying
notification annotations, while hanzoai/notify v1.7.2 is already embedded in
cloud. Two ways to notify, one of them dead and pulling a dependency.
Deleted: cmd/cd-notification, notification_controller/, server/notification/,
util/notification/, the admin CLI command, hack/gen-catalog (generated the
service catalog), the gen-docs notification pass, and the wiring in
server.go and cmd/main.go.
github.com/argoproj now appears ZERO times in go.mod. Both live argoproj
dependencies are gone — pkg/v2 internalized in the previous commit,
notifications-engine deleted here.
go build ./... exit 0.
Co-authored-by: Hanzo Dev <[email protected]>
github.com/argoproj/pkg/v2 was one of two live argoproj dependencies. It is
11 files and 176K total, and we used five packages from it: grpc/http,
kubeclientmetrics, stats, sync, time.
Vendored into util/vendored/ and the dependency dropped from go.mod, so the
gRPC surface (2 references, in grpc-http/forwarders.go) is now ours to remove
on our own schedule rather than upstream's. Kubernetes client-go pulls gRPC
transitively regardless, so this is isolation — a realistic first step — not
a claim that gRPC is gone.
Internalized rather than forked to a shared repo because the only other
consumer, hanzo/gitops, has zero live deployments and zero dependents. A
second repo would be a second thing to version for one caller.
NOTICE carries the Apache-2.0 attribution. go build ./... exit 0.
Co-authored-by: Hanzo Dev <[email protected]>
The last Argo in the core type surface. It is also the seam that matters for
going KMS-native: repo- and cluster- credentials are read through ONE
interface with ONE constructor (NewDB), so a KMS-backed store is a second
implementation, not a rewrite of the 26 files that touch Secrets.
go build ./... exit 0.
Co-authored-by: Hanzo Dev <[email protected]>
Every command is cd-*: cd, cd-server, cd-repo-server,
cd-application-controller, cd-applicationset-controller, cd-cmp-server,
cd-commit-server, cd-dex, cd-git-ask-pass, cd-k8s-auth, cd-notification.
util/argo is util/cd; util/notification/argocd is util/notification/cd.
Preserved deliberately: github.com/argoproj/argocd-example-apps is an
EXTERNAL repo used as an e2e fixture, and notifications-engine + pkg/v2 are
real dependencies. Renaming a URL we do not own would break the tests.
Two bugs I made and caught, both from a careless sed:
- s/argo/cd/g turned 'argocd' into 'cdcd' in two directory names
- renaming the package declaration left every call site saying argo.X
go build ./... exit 0.
Co-authored-by: Hanzo Dev <[email protected]>
The fork was already ours everywhere that matters — our image, our IAM (dex
is not deployed), hanzo kv behind what the env still called REDIS. Only the
vocabulary was upstream's: ARGOCD_* across the Go, the manifests, the docs
and the plugin contract, and mkdocs still titled 'Argo CD' pointing at
argoproj/argo-cd.
ARGOCD_ -> CD_ and REDIS_ -> KV_ across 345 files, plus the 8 e2e/cmp
fixtures that assert the plugin env contract — those had to move with the
binary, which now emits CD_APP_NAME where they expected ARGOCD_APP_NAME.
Left alone deliberately, because renaming them would be wrong:
- util/helm/testdata/redis/ and gitops-engine/.../statefulset*.yaml are
fixtures for a THIRD-PARTY chart named redis, not our config
- util/kustomize/testdata/ likewise
- generated.proto regenerates from types.go, which is already clean
go build ./... exit 0.
LOCKSTEP: the live StatefulSet sets 47 ARGOCD_* names the binary no longer
reads. universe 4a5375735 carries the matching manifest change; they deploy
together or the controller falls back to defaults.
Co-authored-by: Hanzo Dev <[email protected]>
main declared Group = "cd.hanzo.ai" while every CRD, all four Applications and
every tracked object in hanzo-k8s are on apps.hanzo.ai. There are no
cd.hanzo.ai CRDs anywhere, so a build from main binds nothing: the controller
comes up healthy, watches a group with no resources, and silently stops
reconciling the fleet. The deployed image (sha-e1b9244, all three components)
is the only reason this has not fired.
The rename reached further than the group. common.go:215 moved the ownership
annotation to cd.hanzo.ai/tracking-id while live objects carry
apps.hanzo.ai/tracking-id, and the finalizers moved too
(resources-finalizer.cd.hanzo.ai), which would leave existing objects holding
finalizers no running controller removes. Renaming a CRD group plus the
ownership annotation plus the finalizers is a data migration over every managed
object, not a source edit — shipping it as an edit is the defect. Reverting
restores the property that was lost: main is deployable at any time.
Mitigating only by luck: prune is false on all three automated Applications, so
the failure mode is "GitOps stops" rather than "GitOps deletes". Not a design.
Verified: no occurrence was a hostname (checked for the argocd.hanzo.ai-style
substring trap; none), 29 files, zero residual, register.go now byte-identical
to the deployed baseline. go build ./... exits 0. TestGetGlobalProjects and
TestGetAppOfAppSummary fail identically on unmodified origin/main — pre-existing,
not from this change.
If cd.hanzo.ai is still wanted, it needs CRD install, object conversion,
annotation and finalizer rewrite across every tracked resource, and RBAC —
executed deliberately, not carried in a source constant.
Co-authored-by: Hanzo Dev <[email protected]>
apps.hanzo.ai collided head-on with the operator: its App CR already occupies
the resource name `apps.hanzo.ai` (plural `apps`, group `hanzo.ai`), so
`kubectl get apps.hanzo.ai` resolved to the operator's CR, not ours, and
`applications.apps.hanzo.ai` read as a stutter. cd.hanzo.ai gives the delivery
plane its own orthogonal group: applications/applicationsets/appprojects.cd.hanzo.ai
alongside the operator's apps.hanzo.ai. One name per concern.
Mechanically identical to e1b924475 (deploy.hanzo.ai -> apps.hanzo.ai): group
constant, every annotation/label/finalizer domain, the node.Group check, the
leader-election ID, the informer GVRs, RBAC apiGroups, and the 3 CRD manifests.
Also corrects the stale `+groupName=argoproj.io` marker in doc.go, which drove
nothing but misled every reader of this package, and the ArgoCD/argoproj naming
in the hanzo.yml cutover note.
Live cutover (CRD apply, CR re-home, image swap) stays separately greenlit —
hanzo.yml is deliberately build-only.
The CRD kind is Application, so apps.hanzo.ai reads naturally
(applications/applicationsets/appprojects.apps.hanzo.ai). Flips the group
constant (pkg/apis/application/register.go), all annotation/label/finalizer
domains (tracking-id, installation-id, secret-type, refresh, hydrate,
resources-finalizer, etc.), the node.Group check, and the 3 CRD manifests.
Module path github.com/hanzoai/deploy and hanzocd-* object names unchanged.
Co-authored-by: Hanzo Dev <[email protected]>
The config-map/secret settings informer filtered on a HARDCODED literal
'app.kubernetes.io/part-of=argocd' (util/settings/settings.go partOfArgoCDSelector
+ isSettingsObject), not a common.go constant — so the rebuilt binary could not
discover hanzocd-cm/hanzocd-secret labeled part-of=hanzocd and fatal-crashed with
'configmap "hanzocd-cm" not found'. Point the selector + the admin cluster/repo
secret labels at part-of=hanzocd. Completes the operational rebrand.
Co-authored-by: Hanzo Dev <[email protected]>
* feat(api): hard-fork CRD API group argoproj.io -> deploy.hanzo.ai
Hanzo CD hard-fork, phase 1.1. Single source of truth is
pkg/apis/application/register.go's Group constant (Application/AppProject/
ApplicationSet all derive their FullName from it); every other Go call-site
that hardcoded the literal group string is updated to match: the 3 generated
informer GVRs, the app-of-apps nested-Application detector in types.go, the
resource-tree Application-kind cache populator, the 3 NotFound error
constructors in server/application, and the applicationset-controller's
leader-election Lease name/ID (kept in lockstep across Go source + RBAC
resourceNames, or leader election would get RBAC-denied on startup).
CRD YAMLs (application/appproject/applicationset) and every RBAC apiGroups
rule that actually governs our 3 CRDs are repointed to deploy.hanzo.ai, across
both manifests/base/* (namespaced Roles) and manifests/cluster-rbac/* (cluster
scope). Two adjacent things that share the "argoproj.io" string but are NOT
ours are deliberately left untouched: gitops-engine's health-check dispatch
for Argo Workflows' `Workflow` kind, and argocd-server-clusterrole's second
apiGroups block granting read on Argo Workflows' `workflows` resource — both
belong to a separate, unrelated Argoproj-family project we are not forking.
Also untouched, per explicit scope: annotation/label keys (argocd.argoproj.io/*)
and finalizers (*.argoproj.io) that track already-applied live resources, and
argocd-cm.yaml's resource.customizations.ignoreResourceUpdates keys (a narrow
app-of-apps diffing nicety, not build- or RBAC-relevant).
CGO_ENABLED=0 go build ./... verified green.
* ci: wire canonical hanzo.yml + cicd.yml (Hanzo CD image build)
Phase 1.3. Follows the same one-way pattern every hanzo/lux/zoo repo uses:
hanzo.yml declares the image (root Dockerfile -> ghcr.io/hanzoai/deploy) and a
fast go-build sanity test (the multi-stage Dockerfile build is the slow, real
gate); cicd.yml is the ~10-line trigger shim importing hanzoai/ci's reusable
build workflow on the arc pool, secrets from KMS only.
No `deploy:` block yet, matching the hanzoai/cms build-only-first-cutover
pattern: this repo's own live hanzo-cd namespace runs the whole Hanzo fleet's
GitOps, so the prod image/CRD swap is a deliberate separate action (see the
[HELD] universe PR), never an automatic rollout on merge. Every PR/push still
builds and pushes an immutable ghcr.io/hanzoai/deploy:sha-<7>-amd64 image.
* feat(ui): rebrand Argo CD -> Hanzo CD (title, favicon, logo, sidebar)
Phase 1.2. User-facing "Argo CD"/"ArgoCD" text replaced with "Hanzo CD"
across the login page, help modal, settings screens, version-info panel,
sync-options warning, fullscreen-logs title, app.tsx page titles, and
index.html's <title>/noscript text (dropped the now-wrong upstream CLI
doc link rather than invent a hanzo.ai URL that doesn't exist).
Logo/favicon assets replaced with the canonical Hanzo mark (never
hand-drawn, copied from ~/work/hanzo/logo/dist): the two real usages of
Argo's logo collapse onto one Hanzo glyph (mono + white variants) at the
same 5 call sites (login icon + footer, login.scss $logoPath/
$logoNegativePath, sidebar text-logo), preserving the existing CSS
invert() filters so both the light login panel and dark sidebar still
render correctly. Old argologo.svg/argo_o.svg/argo.png deleted (no
longer referenced). favicon-{16x16,32x32}.png added at
ui/src/assets/favicon/ (index.html's links to that path were previously
dead - the directory didn't exist in this checkout). package.json name
argo-cd-ui -> hanzo-cd-ui.
Left alone, deliberately: the two Kubernetes resource-kind icon sets
under ui/src/assets/images/resources/ (unrelated to branding), and
upstream doc/project links (argoproj.io, argo-cd.readthedocs.io) since
we have no equivalent hanzo.ai docs to point to yet - except the login
footer logo's outbound link, which now points to hanzo.ai instead of
argoproj.io (a Hanzo-branded mark linking to the upstream project it
was forked from read as an obvious leftover).
* feat(module): rename Go module github.com/argoproj/argo-cd/v3 -> github.com/hanzoai/deploy
Phase 2. No version suffix on the new path (org policy: never publish our
own Go modules above v1.x.x / with a v2+ suffix) — this fork starts a fresh
v0/v1 module identity rather than carrying the v3 the upstream fork point
had reached.
Mechanical, symmetric rewrite: 704 .go files (import statements only; two
disjoint substitutions applied specific-first so the nested gitops-engine
module path never double-matches), plus go.mod (module line, the
gitops-engine require+replace pair, version reset to v0.0.0-... since a
suffix-less path can't carry a v3 semver), gitops-engine/go.mod, Makefile
(ldflags PACKAGE + 2 TEST_MODULE filters), .golangci.yaml, .goreleaser.yaml,
.mockery.yaml (+ gitops-engine's), Procfile, the codegen/proto generation
scripts (hack/generate-proto.sh, update-codegen.sh, update-openapi.sh), and
20 .proto files' go_package options. Also one OpenTelemetry tracer name
string in gitops-engine/pkg/sync/sync_context.go (a cosmestic label, not an
import, but worth keeping consistent).
CGO_ENABLED=0 go build ./... verified green for both the root module and
the nested gitops-engine module; go vet clean on both; go mod tidy run
(network available) to reconcile go.sum, dependency set unchanged.
Left alone, deliberately: doc-only mentions (docs/snyk/*.html scan reports,
gitops-engine/README.md), a comment-only reference in
.github/workflows/release.yaml, and one Renovate bot config line — none are
build- or codegen-load-bearing. Also left alone: comments citing upstream
GitHub issue URLs (github.com/argoproj/argo-cd/issues/NNNNN) and a handful
of test fixtures using "https://github.com/argoproj/argo-cd.git" as a
representative example repo URL — both are accurate historical/test-data
references, not stale self-references.
---------
Co-authored-by: Hanzo Dev <[email protected]>
zeekayandHanzo Dev