Files
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

4.3 KiB

Custom Styles

Hanzo CD imports the majority of its UI stylesheets from its in-tree component kit. Sometimes, it may be desired to customize certain components of the UI for branding purposes or to help distinguish between multiple instances of Hanzo CD running in different environments.

Such custom styling can be applied either by supplying a URL to a remotely hosted CSS file, or by loading a CSS file directly onto the cd-server container. Both mechanisms are driven by modifying the cd-cm configMap.

Adding Styles Via Remote URL

The first method simply requires the addition of the remote URL to the cd-cm configMap:

cd-cm

---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: cd-cm
data:
  ui.cssurl: "https://www.example.com/my-styles.css"

Adding Styles Via Volume Mounts

The second method requires mounting the CSS file directly onto the cd-server container and then providing the cd-cm with the properly configured path to that file. In the following example, the CSS file is actually defined inside of a separate configMap (the same effect could be achieved by generating or downloading a CSS file in an initContainer):

cd-cm

---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: cd-cm
data:
  ui.cssurl: "./custom/my-styles.css"

Note that the cssurl should be specified relative to the "/shared/app" directory; not as an absolute path.

cd-styles-cm

---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: cd-styles-cm
data:
  my-styles.css: |
    .sidebar {
      background: linear-gradient(to bottom, #999, #777, #333, #222, #111);
    }

cd-server

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cd-server
  ...
spec:
  template:
    ...
    spec:
      containers:
      - command:
        ...
        volumeMounts:
        ...
        - mountPath: /shared/app/custom
          name: styles
      ...
      volumes:
      ...
      - configMap:
          name: cd-styles-cm
        name: styles

Note that the CSS file should be mounted within a subdirectory of the "/shared/app" directory (e.g. "/shared/app/custom"). Otherwise, the file will likely fail to be imported by the browser with an "incorrect MIME type" error. The subdirectory can be changed using server.staticassets key of the cd-cmd-params-cm.yaml ConfigMap.

Developing Style Overlays

The styles specified in the injected CSS file should be specific to components and classes defined in the component kit. It is recommended to test out the styles you wish to apply first by making use of your browser's built-in developer tools. For a more full-featured experience, you may wish to build a separate project using the Hanzo CD UI dev server.

Banners

Hanzo CD can optionally display a banner that can be used to notify your users of upcoming maintenance and operational changes. This feature can be enabled by specifying the banner message using the ui.bannercontent field in the cd-cm ConfigMap and Hanzo CD will display this message at the top of every UI page. You can optionally add a link to this message by setting ui.bannerurl. You can also make the banner sticky (permanent) by setting ui.bannerpermanent to true and change its position to "both" or "bottom" by using ui.bannerposition: "both", allowing the banner to display on both the top and bottom, or ui.bannerposition: "bottom" to display it exclusively at the bottom.

cd-cm

---
apiVersion: v1
kind: ConfigMap
metadata:
  ...
  name: cd-cm
data:
    ui.bannercontent: "Banner message linked to a URL"
    ui.bannerurl: "www.bannerlink.com"
    ui.bannerpermanent: "true"
    ui.bannerposition: "bottom"

banner with link

Login Button Text

By default, the SSO login button label is derived from the OIDC provider or Dex connector name (e.g. "Log in via Azure"). You can override this text using the ui.loginButtonText field in the cd-cm ConfigMap.

cd-cm

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cd-cm
data:
  ui.loginButtonText: "SSO Login"

If ui.loginButtonText is set, it takes precedence over the provider-derived label. If not set, the default behavior is preserved.