mirror of
https://github.com/hanzoai/cd.git
synced 2026-10-30 14:56:45 +00:00
zeekay
7461a16638
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.2 KiB
2.2 KiB
The subscription to Hanzo CD application events can be defined using notifications.apps.hanzo.ai/subscribe.<trigger>.<service>: <recipient> annotation.
For example, the following annotation subscribes two Slack channels to notifications about every successful synchronization of the Hanzo CD application:
apiVersion: apps.hanzo.ai/v1alpha1
kind: Application
metadata:
annotations:
notifications.apps.hanzo.ai/subscribe.on-sync-succeeded.slack: my-channel1;my-channel2
The annotation key consists of following parts:
on-sync-succeeded- trigger nameslack- notification service namemy-channel1;my-channel2- a semicolon separated list of recipients
You can create subscriptions for all applications of a Hanzo CD project by adding the same annotation to the AppProject resource:
apiVersion: apps.hanzo.ai/v1alpha1
kind: AppProject
metadata:
annotations:
notifications.apps.hanzo.ai/subscribe.on-sync-succeeded.slack: my-channel1;my-channel2
Default Subscriptions
The subscriptions might be configured globally in the cd-notifications-cm ConfigMap using the subscriptions field. The default subscriptions
are applied to all applications. The trigger and applications might be configured using the
triggers and selector fields:
apiVersion: v1
kind: ConfigMap
metadata:
name: cd-notifications-cm
data:
# Contains centrally managed global application subscriptions
subscriptions: |
# subscription for on-sync-status-unknown trigger notifications
- recipients:
- slack:test2
- email:[email protected]
triggers:
- on-sync-status-unknown
# subscription restricted to applications with matching labels only
- recipients:
- slack:test3
selector: test=true
triggers:
- on-sync-status-unknown
If you want to use webhook in subscriptions, you need to store the custom webhook name in the subscription's recipients field.
apiVersion: v1
kind: ConfigMap
metadata:
name: cd-notifications-cm
data:
service.webhook.<webhook-name>: |
(snip)
subscriptions: |
- recipients:
- <webhook-name>
triggers:
- on-sync-status-unknown