Coding Guideline — Argo CD interaction model

This repo holds values and cached charts. It does NOT own Argo CD Application or ApplicationSet manifests. Those live in the sister repo:

github.com/Meesho/devops-infra-argo-config

A merge to main here is a deploy event for every cluster whose Argo Application points at a path in this repo. The Argo Application defines the routing (which path on which cluster, sync policy, retry, prune); we define what that path renders to.

Hard separation

Concern	Owns it
`helm-templates/<chart>/` (cached/forked chart)	this repo
`helm-overrides/<cluster>/<app>/custom-values.yaml` (per-cluster values)	this repo
`manifests/storageclass/`, `manifests/priorityclass/<cluster>/` (singletons)	this repo
Argo `Application` (cluster, path, repoURL, targetRevision, destination namespace)	sister repo
Argo `ApplicationSet` (cluster generators, templating fan-out)	sister repo
`syncPolicy.automated.{prune,selfHeal}` decision	sister repo
`syncPolicy.syncOptions` (CreateNamespace, ServerSideApply)	sister repo
Sync waves / hooks via `argocd.argoproj.io/sync-wave` annotations	this repo (when expressed inside chart templates or raw sidecar manifests)

What this means for the agent

Never add or edit a file matching Application*.yaml / ApplicationSet*.yaml here. If the task asks for one, redirect to the sister repo. See escalation-matrix.md row 5.
When introducing a new app to a cluster, the change is a paired PR: (a) a PR here adding helm-overrides/<cluster>/<newapp>/custom-values.yaml, and (b) a PR in the sister repo adding the matching Application manifest. Both must merge before the app deploys.
When introducing a new cluster, the paired PR in the sister repo updates the ApplicationSet cluster generator. See ../platform/procedures/onboard-new-cluster.md.
When removing an app, deboard the Argo Application first (sister repo), let Argo prune, then remove the override directory here. See ../platform/procedures/deboard-app.md.

Sync policy: where the decision lives

syncPolicy.automated.prune and syncPolicy.automated.selfHeal live in the sister repo's Application spec. Convention on the platform:

Manual sync default for infra components on prod clusters. Sync is a deliberate human click after a merge. Rationale documented in wiki/analyses/ADR-A5-manual-sync-default-for-infra.md.
Auto-sync is reserved for low-risk leaf components (e.g., kube-state-metrics, monitoring agents) where reconciliation drift is benign.

Agents editing values here should assume the sync click is the safety gate. A merged PR is not yet deployed.

Validating values before merge

The agent's responsibility is that the values render correctly. Argo CD will materialize the rendered output via helm template-equivalent server-side. Use the same command locally:

helm template <release> helm-templates/<chart> \
  -f helm-overrides/<cluster>/<app>/custom-values.yaml

If the chart has subchart dependencies (Chart.yaml dependencies:), run helm dependency update helm-templates/<chart> before templating, otherwise render will fail with found in Chart.yaml, but missing in charts/ directory.

For raw-manifest sidecars (<extra>.yaml files in the override dir), validate with kubectl apply --dry-run=client -f <file>. See ../platform/schemas/raw-manifest-sidecar-schema.md.

Common failure modes

Symptom	First read
`Sync` button click results in `OutOfSync` that won't resolve	../platform/runbooks/argocd-sync-failure.md
Pods land but stay `Pending`	../platform/runbooks/pod-pending-scheduling.md
Ingress 5xx after a Contour values change	../platform/runbooks/ingress-down.md

4.7 KiB Raw Blame History