devops-lib-gcp/docs/wiki/pages/deploy/argocd-sync.md

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/<cluster>/<team>-<app>.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 <argoIncubator> (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 <env>-<app_name> — forces ArgoCD to re-read Helm values from Git.
• argocd app sync <env>-<app_name> — 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 — broader deploy lifecycle including user input and canary enforcement
• Dockerfile templates — renderTemplate used in both argo and helm steps

Sources

(no raw/ sources at bootstrap)

Notes

---

← Wiki index