> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources. # ArgoCD Sync Sequence The 4-step ArgoCD deploy sequence in `deployArgoCD.groovy` uses Git as the API: each step commits to a config repo, opens a PR, merges it, and then triggers ArgoCD to pick up the change. ## Where it applies in this repo `src/com/meesho/stages/deployArgoCD.groovy` **Step 1 — `update_argo_repo`** - Reads `deployment.yaml` for the deployable. - Renders `argoApp.yaml` template → `devops-argo-config/applications_v2//-.yaml`. - Commits + opens PR against `argoBranch` + merges + deletes branch. - Sets `value_binding1['helm_values_path']` so the ArgoCD app knows where to find Helm values. **Step 2 — `refresh_app_of_apps`** - Runs `argocd app sync ` (the incubator app-of-apps). - This causes ArgoCD to discover the new/updated Application manifest from Step 1. - Uses `--http-retry-max 3 --retry-backoff-duration 1m`. **Step 3 — `update_helm_repo`** - Reads `deployment.yaml` + `values_properties.yaml` from `devops-helm-charts`. - Renders `values.yaml` (or `node-values.yaml`, `go-values.yaml`, etc.) template. - Enforces canary for sp0/up0 prd services: `enabled=true`, `skipAnalysis=false`, `enableManualPromotion=true`. - Commits + opens PR against `helmBranch` + merges + deletes branch. **Step 4 — `refresh_and_sync`** - `argocd app get --hard-refresh -` — forces ArgoCD to re-read Helm values from Git. - `argocd app sync -` — triggers rollout. - Returns exit code 0 on success; any non-zero result fails the build. ## Why this design Using Git PRs as the deployment mechanism means every config change is auditable in GitHub history. ArgoCD polls its source repos on a configurable interval, but `hard-refresh` forces an immediate re-read instead of waiting for the poll cycle. The app-of-apps pattern allows ArgoCD to manage thousands of Application resources without manual registration. Steps 2 (`refresh_app_of_apps`) and 4 (`refresh_and_sync`) are **not interchangeable**. For a first-deploy service, step 2 must run before step 4: without step 2, the ArgoCD Application object created in step 1 hasn't been discovered yet, and step 4 will target a non-existent app. The four-step order is load-bearing. ## Related - [Deploy ArgoCD](../04-DEPLOY-ARGOCD.md) — broader deploy lifecycle including user input and canary enforcement - [Dockerfile templates](../08-DOCKERFILE-TEMPLATES.md) — renderTemplate used in both argo and helm steps ## Sources (no raw/ sources at bootstrap) ## Notes --- [← Wiki index](../../index.md)