serverSideDiff finds the field set the CD controller owns by looking its manager
up by name. The live YAML fixtures were renamed to cd-controller; the
predicted-live JSON beside them still said argocd-controller, and the diff reads
both. Every server-side-diff case that asks "which fields are mine" failed with
"no managed fields found for manager: cd-controller" — not because the logic is
wrong, but because the two halves of the same fixture disagreed about who
applied it.
Seven JSON fixtures now name the same manager as the YAML they pair with.
pkg/diff goes green; the full gitops-engine module is 12/12.
Co-authored-by: Hanzo Dev <[email protected]>
The image carried LABEL org.opencontainers.image.source pointing at
github.com/argoproj/argo-cd, the upstream we forked from. GitHub links a
container package to the repo that label names; it cannot link to a repo outside
the org, so ghcr.io/hanzoai/cd was created UNLINKED, and an unlinked package
defaults to private. That is the whole reason v3.6.0 and v3.6.1 pushed fine and
could not be pulled:
failed to fetch anonymous token: 401 Unauthorized
Confirmed by comparing against the packages that work — every one of them is
linked and public:
deploy public repo=hanzoai/cd
cloud public repo=hanzoai/ai
cd PRIVATE repo=UNLINKED
So this was never a visibility setting someone forgot to flip; it was a stale
label doing exactly what it says. Fixing the label is the root cause, and it
keeps visibility derived from the repo rather than hand-set in a second place.
Also dropped the hanzocd-notifications symlink: the notification subsystem was
deleted in b2d7140a (we use hanzoai/notify), so the link pointed at a command
the binary no longer serves.
Co-authored-by: Hanzo Dev <[email protected]>
The Go side was renamed; the UI was not. It still compares resource groups
against 'argoproj.io' and writes argocd.argoproj.io/* annotations, so it and
the API no longer agree on what anything is called.
Worst of these is the finalizer. The controller injects and honors
resources-finalizer.apps.hanzo.ai; the create panel's cascade-delete checkbox
wrote resources-finalizer.argocd.argoproj.io. Ticking the box produced a
finalizer nothing reads — the user is told deletion will cascade, and it does
not. The live Applications already carry the apps.hanzo.ai form; only the UI
disagreed.
The group comparisons fail the same way, quietly: node.group === 'argoproj.io'
guards the ApplicationSet and Application branches in the resource tree,
detail panes, and extension tab lookup, and the backend now sends
apps.hanzo.ai, so those branches stopped being taken.
Values follow whichever constant owns them, rather than a blanket rename:
sync-wave / hook / deletion-approved cd.hanzo.ai/* (gitops-engine sync
vocabulary)
refresh / managed-by-url / link. / apps.hanzo.ai/* (application_annotations
notice. / pref. / group / apiVersion .go, common.go)
Untouched, because they are other people's CRDs and renaming them breaks
icon and subscription lookup for anyone running those products:
promoter.argoproj.io, notifications.argoproj.io.
tsc --noEmit clean; 22 suites / 263 tests / 32 snapshots pass.
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]>
The repo is cd. The binaries are cd-*. The API group is apps.hanzo.ai, the
annotations are cd.hanzo.ai, the UI is cd.hanzo.ai. hanzo.yml was the last
place still saying `deploy` — the name from before the rename — so the
canonical build would have pushed the renamed engine to the old package.
universe infra/k8s/hanzo-cd/README.md has documented the engine as
ghcr.io/hanzoai/cd all along; this is the build target catching up to the
doc, not a new decision.
Also corrected in passing: the header still described the image as building
`notifications`, deleted in b2d7140a (we use hanzoai/notify), and still
called the repo hanzoai/deploy.
Removing v1alpha1 before deploying the binary that speaks v1 took the control
plane down on 2026-07-28: the running controller listed *v1alpha1.Application
against an API that no longer served it, CrashLooped, and 65 Applications plus
the ApplicationSet were lost.
The workloads survived only because the resources-finalizer never fired, and
recovery was possible only because everything was reconstructible from git.
Every CRD migration step was individually correct. The unchecked thing was
which version the running consumer speaks.
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]>
Carried off the legacy master branch before deleting it. master was the
pre-fork upstream line — it still declared Group = "argoproj.io" and
AnnotationKeyAppInstance = "argocd.argoproj.io/tracking-id", which is exactly
the identity being purged from this fork, so the branch itself had to go.
Its only two commits were this bump and a NOTICE attributing Argo CD upstream.
main already carries that NOTICE (Apache-2.0 attribution intact), so this line
was the sole thing that would have been lost. go build ./... exits 0 on 1.26.5.
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]>
The repo carries the upstream LICENSE but no NOTICE, so nothing states which
project the code derives from or who holds copyright on it. Added in the same
form the other forks here use.
Co-authored-by: Hanzo Dev <[email protected]>
Superseded: the Hanzo GitHub App pushes a webhook, so the forge tracks GitHub
without a per-repo workflow. This file called git.hanzo.ai/api/v1/.../mirror-sync
— a Gitea API for a system we no longer drive — and would sit inert in every repo.
One mechanism, in one place, instead of ~350 copies of a cron.
git.hanzo.ai mirrors this repo by PULL on a ~10-minute interval, and arcd runs
CI/CD there — so every push waited out that interval before anything built.
This asks Gitea to pull HEAD immediately.
Latency only: the repo already mirrors via the App webhook, so a missing
HANZO_GIT_TOKEN or a failed curl is non-fatal and never fails the push.
Idempotent (mirror-sync just pulls HEAD) and concurrency-coalesced.
This workflow ran on a self-hosted actions-runner-controller pool. ARC is
decommissioned: CI executes inside git.hanzo.ai (Gitea Actions, .hanzo/workflows)
and delivery is cd.hanzo.ai reconciling the reviewed image pin in
hanzoai/universe. GitHub is a mirror and runs nothing.
Removed rather than repointed — there is no GitHub-side pool to move to, and
leaving it would keep ARC load-bearing.
This workflow ran on a self-hosted actions-runner-controller pool. ARC is
decommissioned: CI executes inside git.hanzo.ai (Gitea Actions, .hanzo/workflows)
and delivery is cd.hanzo.ai reconciling the reviewed image pin in
hanzoai/universe. GitHub is a mirror and runs nothing.
Removed rather than repointed — there is no GitHub-side pool to move to, and
leaving it would keep ARC load-bearing.
origin/main renamed the API group apps.hanzo.ai -> cd.hanzo.ai (apps.hanzo.ai
collided with the operator's App CR) but only in the overlays and CRDs; this
branch had renamed every object argocd-* -> hanzocd-* and regenerated the flat
install manifests against the old group.
Resolution keeps both axes orthogonal: the group is cd.hanzo.ai everywhere (it
must match common.go and the applicationset leader-election ID), the object
naming/labels stay hanzocd-* / part-of: hanzocd so the settings informer finds
its config. The generated install manifests are re-synced to the resolved
overlays, which also carries the group rename that upstream left out of them.
Go tree is byte-identical to origin/main.
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 server image expects the apps.hanzo.ai API group (register.go), hanzocd-*
config object names (common.go ArgoCDConfigMapName=hanzocd-cm, ...), and a
settings informer that selects app.kubernetes.io/part-of=hanzocd. The base
manifests still emitted argocd-* object names, part-of: argocd, and the stock
quay.io/argoproj/argocd image, so a fresh render produced config/RBAC the
running server cannot find (informer misses part-of=argocd config; server reads
hanzocd-cm but manifest creates argocd-cm) and would run the upstream image.
- Rename every object name and file argocd-* -> hanzocd-* (SA/Role/RoleBinding/
ClusterRole/ClusterRoleBinding/Service/Deployment/StatefulSet/ConfigMap/Secret/
NetworkPolicy), referential integrity preserved (roleRef/subjects/selectors/
configMapRef).
- Flip app.kubernetes.io/part-of: argocd -> hanzocd so the settings informer
finds the config objects.
- Point the image at ghcr.io/hanzoai/deploy (kustomize image transform +
container image refs).
- Match the hanzocd-cm ignoreResourceUpdates keys for the CD's own Application to
apps.hanzo.ai (argoproj.io_Application -> apps.hanzo.ai_Application; refresh/
hydrate annotation domains). External argoproj.io_Rollout / rollout.argoproj.io
/ notifications refs are left as-is.
- Drop the vestigial argoproj.io workflows create grant from hanzocd-server
ClusterRole (no Argo Workflows in this install).
- Regenerate the flat install manifests (install/namespace-install/core-install
and hydrator variants) from the corrected overlays.
RBAC now grants apps.hanzo.ai on applications/applicationsets/appprojects for
hanzocd-server and hanzocd-application-controller, so a fresh deploy keeps the
running apps.hanzo.ai server up. CRDs unchanged in group/kind/version (match the
live apps.hanzo.ai CRDs). Image-internal paths (/home/argocd, /usr/local/bin/
argocd) match the built image and are unchanged.
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 askpass server sets GIT_ASKPASS=hanzocd + ARGOCD_BINARY_NAME=argocd-git-ask-pass;
cmd/main.go dispatches on ARGOCD_BINARY_NAME (env override) matched against
common.CommandGitAskPass. The rebrand moved the constant to hanzocd-git-ask-pass but
this hardcoded override value stayed argocd-git-ask-pass -> no match -> fell through to
the main CLI -> cobra tried to exec a plugin 'argocd-Username...' -> git auth failed.
Point the override at hanzocd-git-ask-pass. No symlink needed (dispatch is env-driven).
Co-authored-by: Hanzo Dev <[email protected]>
The git credential askpass hardcoded GIT_ASKPASS=argocd (util/askpass/server.go),
but the rebuilt image ships /usr/local/bin/hanzocd — so 'git fetch' failed with
'cannot run argocd' -> 'could not read Username for github.com' -> repo-server
could not render manifests. Point it (and the web-terminal LookPath, CLI config
dir, and session issuer) at hanzocd. This is the last runtime argocd binary ref.
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]>
set-vars always emitted quay_image_name, so the quay docker/login-action ran with
empty RELEASE_QUAY_* secrets → 'Username and password required' failed the build.
Empty quay_image_name skips the quay login and drops quay from TAGS; GHCR push
uses github.actor + GITHUB_TOKEN (packages: write).
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