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

2.8 KiB

Failed to parse new settings

error converting YAML to JSON

YAML syntax is incorrect.

incorrect:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cd-notifications-cm
data:
  service.slack: |
    token: $slack-token
    icon: :rocket:

correct:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cd-notifications-cm
data:
  service.slack: |
    token: $slack-token
    icon: ":rocket:" # <- diff here

service type 'xxxx' is not supported

Check the cd-notifications controller version. For example, the Teams integration support started in v1.1.0.

Failed to notify recipient

notification service 'xxxx' is not supported

You have not defined xxxx in cd-notifications-cm or parsing failed.

GitHub.repoURL (\u003cno value\u003e) does not have a / using the configuration

Likely caused by an Application with multiple sources:

spec:
  sources:  # <- multiple sources
  - repoURL: https://github.com/exampleOrg/first.git
    path: sources/example
  - repoURL: https://github.com/exampleOrg/second.git
    targetRevision: "{{branch}}"

The standard notification template only supports a single source ({{.app.spec.source.repoURL}}). Use an index to specify the source in the array:

template.example: |
  github:
    repoURLPath: "{{ (index .app.spec.sources 0).repoURL }}"

Error message POST https://api.github.com/repos/xxxx/yyyy/statuses/: 404 Not Found

This case is similar to the previous one, you have multiple sources in the Application manifest. Default revisionPath template {{.app.status.operationState.syncResult.revision}} is for an Application with single source.

Multi-source applications report application statuses in an array:

status:
  operationState:
    syncResult:
      revisions:
        - 38cfa22edf9148caabfecb288bfb47dc4352dfc6
        - 38cfa22edf9148caabfecb288bfb47dc4352dfc6
Quick fix for this is to use `index` function to get the first revision:
```yaml
template.example: |
  github:
    revisionPath: "{{index .app.status.operationState.syncResult.revisions 0}}"

config referenced xxx, but key does not exist in secret

  • If you are using a custom secret, check that the secret is in the same namespace
  • You have added the label: app.kubernetes.io/part-of: cd to the secret
  • You have tried restarting cd-notifications controller

Example:

Secret:

apiVersion: v1
kind: Secret
metadata:
  name: cd-slackbot
  namespace: <the namespace where cd is installed>
  labels:
    app.kubernetes.io/part-of: cd
type: Opaque
data:
  slack-token: <base64encryptedtoken>

ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: cd-notifications-cm
data:
  service.slack: |
    token: $cd-slackbot:slack-token