zeekay
187be9e719
repository.proto and 11 sibling hand-written .proto files referenced generated.proto's application/v1alpha1 types under the pre-fork package path (github.com.argoproj.argo_cd.v3...); protoc silently kept compiling because generated.proto still carried that same stale package too. Point both at the real, mechanically-derived path (github.com.hanzoai.cd.pkg.apis.application.v1alpha1, no v3 segment) and regenerate everything protoc/go-to-protobuf own: generated.proto/pb.go, every pkg/apiclient and reposerver/cmpserver/commitserver *.pb.go, assets/swagger.json, and the CRD manifests. That regeneration surfaced a second, unrelated bug: hack/gen-crd-spec stamped app.kubernetes.io/part-of: cd on the CRDs, but util/settings.isSettingsObject (and the ConfigMap informer built on it) only ever recognizes part-of=hanzocd. The same wrong "cd" value was baked into cmd/cd/commands/admin/settings.go's setSettingsMeta and the shared test/testdata.go fixtures ~30 files import — util/settings' own test suite was panicking on an empty slice because its fixture was invisible to the informer it was supposedly seeding. Fixed the label everywhere it's produced or asserted in the settings path; left the ~90 unrelated part-of:"cd" literals in other packages' local test fixtures alone since they never touch this selector. Also dropped 25 "TODO: Remove deprecated <dead upstream issue link>" comments that duplicated the real explanation already sitting one line away (a proper `Deprecated:` godoc, a cobra Deprecated field, or a nolint:staticcheck marker) — kept the explanation, dropped the link, per the standing rule for these citations. And repointed the two Grafana dashboards' job selector from argocd-server-metrics, a Service the manifests never create, to hanzocd-server-metrics, the one they do.
Hanzo CD Installation Manifests
Four sets of installation manifests are provided:
Normal Installation:
-
install.yaml - Standard Hanzo CD installation with cluster-admin access. Use this manifest set if you plan to use Hanzo CD to deploy applications in the same cluster that Hanzo CD runs in (i.e. kubernetes.default.svc). Will still be able to deploy to external clusters with inputted credentials.
-
namespace-install.yaml - Installation of Hanzo CD which requires only namespace level privileges (does not need cluster roles). Use this manifest set if you do not need Hanzo CD to deploy applications in the same cluster that Hanzo CD runs in, and will rely solely on inputted cluster credentials. An example of using this set of manifests is if you run several Hanzo CD instances for different teams, where each instance will be deploying applications to external clusters. Will still be possible to deploy to the same cluster (kubernetes.default.svc) with inputted credentials (i.e.
cd cluster add <CONTEXT> --in-cluster --namespace <YOUR NAMESPACE>).
Note
Hanzo CD CRDs are not included into namespace-install.yaml. and have to be installed separately. The CRD manifests are located in manifests/crds directory. Use the following command to install them:
kubectl apply -k https://github.com/hanzoai/cd/manifests/crds\?ref\=stable
High Availability:
-
ha/install.yaml - the same as install.yaml but with multiple replicas for supported components.
-
ha/namespace-install.yaml - the same as namespace-install.yaml but with multiple replicas for supported components.