Files
cd/docs/try_cd_locally.md
zeekay 7461a16638 docs: drop Argo branding, delete pre-fork upstream history, fix broken links
Rewrites remaining Argo/ArgoCD/argocd/argoproj prose in docs/ to Hanzo CD,
in our own voice only. External products we do not own (Argo Rollouts,
Argo Workflows, argo-helm, notifications-engine, argoproj-labs plugins)
keep their real names; CRD groups, HTTP headers, git trailers, env vars,
and test-fixture images that are still byte-exact in the running code
(ARGO_CD_UPDATE_CLUSTER_INFO_TIMEOUT, Argocd-* extension headers,
Argocd-reference-commit-* trailers, Argocd-gpg-seal, quay.io/argoprojlabs
cd-e2e-container) are left untouched.

Deletes docs/operator-manual/upgrading/1.0-1.1.md through 3.4-3.5.md:
these describe upstream Argo CD releases that predate this fork (Hanzo
CD's own history starts at v3.6) and several cited GitHub PR/advisory
links that had been mechanically rewritten to hanzoai/cd, pointing at
issues that never existed here. Deletes docs/developer-guide/dependencies.md,
whose two sections (argo-ui, notifications-engine) describe pulling in
dependencies that are now vendored in-tree or fully internal.

Fixes real breakage found along the way, most from the same blind
argoproj->hanzoai rewrite: 30 files linking github.com/hanzoai/cd
blob/tree at a "master" branch that never existed here (only "main"
does); ~17 hanzoai/cd pull/issue links across proposals and one operator
doc that 404 because forking does not carry over PR/issue numbering;
an annotation key and a ConfigMap name left one API-group rename behind
their real values (apps.hanzo.ai/*, cd-rbac-cm); a page rename
(Argo-CD-Integration.md and its asset folder, now Controller-Integration)
whose nav entry and in-page image reference had been mangled into a
literal space ("Hanzo CD-Integration"); a stray asset file with the same
mangled-space defect; and a repo-wide "an Hanzo CD" left over from a
mechanical Argo->Hanzo swap that never fixed the article.

mkdocs.yml: trims the Upgrading nav to the one real entry, drops
dependencies.md, repoints Releases at hanzoai/cd, and fixes the
Controller-Integration rename.

Verified with a strict mkdocs build (0 warnings) after the fixes above.

Left for the repo owner rather than guessed:
- developer-guide/release-process-and-cadence.md and
  proposals/feature-bounties*.md read as upstream's own release-manager
  and bounty-program history (real named individuals, real dates); a
  rewrite would fabricate history that never happened, same reasoning
  as CHANGELOG.md.
- assets/versions.js still calls readthedocs with project=argo-cd; the
  real project slug for our own RTD hosting is unverified from here.
- signed-release-assets.md's cosign --certificate-identity-regexp still
  names .github/workflows/image-reuse.yaml, which does not exist in this
  repo (no .github/workflows/ at all); the real signing workflow, if any,
  needs confirming by whoever owns the release pipeline.
- maintaining-internal-cd-forks.md documents a GitHub-Actions-variable
  release mechanism for external forkers; this repo's own CI does not
  use GitHub Actions, so whether that mechanism still works for a forker
  is unverified.
2026-09-05 01:14:03 -07:00

2.4 KiB
Raw Permalink Blame History

Try Hanzo CD Locally

Tip

This guide assumes you have a grounding in the tools that Hanzo CD is based on. Please read understanding the basics to learn about these tools.

Follow these steps to install Kind for local development and set it up with Hanzo CD.

To run a Hanzo CD development environment review the developer guide for running locally.

Install Kind

Install Kind following their quick-start instructions.

Create a Kind Cluster

Once Kind is installed, create a new Kubernetes cluster with:

kind create cluster --name cd-cluster

This will create a local Kubernetes cluster named cd-cluster.

Set Up kubectl to Use the Kind Cluster

After creating the cluster, set kubectl to use your new kind cluster:

kubectl cluster-info --context kind-cd-cluster

This command verifies that kubectl is pointed to the right cluster.

Install Hanzo CD on the Cluster

You can now install Hanzo CD on your kind cluster. First, apply the Hanzo CD manifest to create the necessary resources:

kubectl create namespace cd
kubectl apply -n cd --server-side --force-conflicts -f https://raw.githubusercontent.com/hanzoai/cd/main/manifests/install.yaml

Note

The --server-side --force-conflicts flags are required because some Hanzo CD CRDs exceed the size limit for client-side apply. See the getting started guide for more details.

Expose Hanzo CD API Server

By default, Hanzo CD's API server is not exposed outside the cluster. You need to expose it to access the UI locally. For development purposes, you can use Kubectl 'port-forward'.

kubectl port-forward svc/cd-server -n cd 8080:443

This will forward port 8080 on your local machine to the Hanzo CD API server’s port 443 inside the Kubernetes cluster.

Access Hanzo CD UI

Now, you can open your browser and navigate to http://localhost:8080 to access the Hanzo CD UI.

Log in to Hanzo CD

To log in to the Hanzo CD UI, you'll need the default admin password. You can retrieve it from the Kubernetes cluster:

kubectl -n cd get secret cd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -d

Use the admin username and the retrieved password to log in.

You can now move on to step #2 in the Getting Started Guide.