mirror of
https://github.com/hanzoai/cd.git
synced 2026-10-30 14:56:45 +00:00
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.
2.8 KiB
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: cdto the secret - You have tried restarting
cd-notificationscontroller
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