The fork's engine now declares its real repo path so consumers (cloud
clients/deploy) can require it as a pinned version with NO replace/alias —
resolving the argoproj-path import that could only be satisfied by a filesystem
replace. Parent (github.com/hanzoai/deploy/v3) keeps its local replace onto
./gitops-engine for its own build. 243 files, module-path substitution only.
The fork was tracked by two Hanzo branches: hanzo/v3.4.5 (the rebranded
release lineage production cuts over to, module github.com/hanzoai/deploy/v3,
builds ghcr.io/hanzoai/deploy) and feat/hanzo-gitops-engine (a doc-only branch
off the unbranded master mirror, still on the argoproj module, carrying one
note about how cloud embeds the gitops-engine submodule for /v1/deploy).
The second branch is not a second rebrand — it never rebranded, never built an
image, and describes cloud's not-yet-wired P2b consumer wiring. Its one durable
fact is the submodule embedding contract: gitops-engine keeps its argoproj
module path (renaming it breaks the parent), and cloud consumes it in-process
via a consumer-side filesystem replace with the k8s pins living on the consumer.
Record that on the release lineage where the fork's operating notes live, scoped
so the version specifics defer to the cloud consumer rather than rot here, and
retire the doc-only branch.
Redis is the store the four processes share, not a cache any of them could
skip. Classified by primitive, SetItem/GetItem/SetNX read as a cache and the
conclusion is that redis is droppable. Classified by who writes and who reads,
argocd-server has no cluster informers and cannot compute a resource tree at
all: the controller writes it, the server reads it, and the two run on
different nodes. Three more flows cross the same boundary, one of them pub/sub,
which twoLevelClient delegates only to the external cache — so an in-memory L1
cannot carry it and InMemoryCache answers OnUpdated with a stub. Record the
flows, and that there is no in-memory path to reach for: an empty --redis
defaults to the redis address, dial errors are not ErrCacheMiss, and a nil
client panics inside Init's goroutines where nothing can recover it.
The revoked token list gets a bound, not a store. Its only writer is logout,
and it holds an entry for exactly as long as the token it revokes, so its whole
job is the gap between logging out and expiring. Redis down preserves the list;
redis flushed empties it, and redis runs here without a PVC, so upstream
already fails open. A store bought to shorten that gap complects session
lifetime with revocation state when setting users.session.duration bounds it
directly, and the durable case — API keys — is already checked against
argocd-cm without redis.
The git-ref SetNX is a real ownership claim, which reading DisableOverwrite as
a cache-write option missed. It is still advisory: the loser of the race
proceeds as owner on timeout, so losing it costs a duplicate ls-remote, not
correctness, and ha has no job here.
Also record that argocd-server writes server.secretkey back into argocd-secret,
which a KMSSecret template that omits it would flap against every resync, and
that the key encrypts the OIDC tokens redis holds.
The rebrand is a substitution, not an artifact: one command reproduces all 627
files byte-for-byte, so it is regenerated when a lineage is adopted rather than
carried on a second branch that rots. master mirrors upstream unbranded and
builds nothing.
LLM.md is the doc home, so it carries the things a reader has to know
before touching this fork and cannot infer from the tree:
- the two lineages and why an image from master is not a rebuild of
v3.4.5, with the merge-base fact that proves it
- that enabling Actions arms upstream's quay.io workflows, and the
per-workflow disable that must accompany it
- the OIDC contract iam2 implements against, taken from the OIDCConfig
struct rather than invented, with the claim mapped to the one
SuperAdmin predicate owner == "admin" via group membership
- that dex is a husk and the real identity hole is admin.enabled=true
- the redis trade written for a decision: what co-residency buys, what it
costs at repo-server's trust boundary, and the third option
- why the docker.io bases are not repointed yet
NOTICE follows the house Hanzo-first pattern: Hanzo CD on top, the fork
stated plainly with the upstream tag and commit it was taken at, then
upstream retained below. Upstream ships no NOTICE, so there is nothing to
propagate under Section 4(d), and LICENSE is their Apache-2.0 text
verbatim. Copyright is claimed only over what we authored; the tree is
overwhelmingly The Argo Authors' work and says so.
hanzo-image.yml publishes ghcr.io/hanzoai/deploy from Hanzo runners. It is
one file, identical on master and on hanzo/**, so the two lineages do not
drift apart in how they build.
Upstream's image.yaml and release.yaml are left untouched. They are
dormant today because GitHub disables workflows on a fork, and only
pages-build-deployment is registered. That dormancy is load-bearing:
image.yaml fires on a push to master and release.yaml on a v* tag, both
onto ubuntu-24.04 runners and both publishing to quay.io/argoproj. Turning
Actions on to run this workflow arms those at the same time, so enabling
must be paired with disabling them per workflow.
The Dockerfile's docker.io build bases are not repointed yet: hanzoai/node
publishes 18.19.0-alpine where the UI build needs 24.x, and
hanzoai/{ubuntu,golang} are private, so their tags cannot be enumerated to
pin them.
Same mechanical rename as on master, applied to the v3.4.5 release
lineage, which is the code production actually runs. Targets were
re-enumerated against this tree rather than reused from master.
This branch exists so the first Hanzo CD image is a like-for-like
cutover: identical argo-cd code, published from our registry by our CI.
Master is a different lineage — VERSION 3.6.0, 823 commits ahead of
v3.4.5 and missing 98 of its backports — so an image built there would
change the code as well as the registry. Moving the lineage is its own
change, gated separately.
go build ./cmd/... passes before and after the rename.
* fix: remove last-applied-annotation from predicted and live for comparison
Signed-off-by: Peter Jiang <[email protected]>
(cherry picked from commit e15ac5feebb52d60c41f7911d3b96139d5f4ce06)
* retry merge
Signed-off-by: Peter Jiang <[email protected]>
---------
Signed-off-by: Peter Jiang <[email protected]>
Signed-off-by: Peter Jiang <[email protected]>
zeekay
