59 lines
2.9 KiB
Markdown
59 lines
2.9 KiB
Markdown
<!-- m-wiki: type=concept slug=argocd-sync topic=deploy base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
|
|
|
|
> 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](../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
|
|
|
|
<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
|
|
|
|
---
|
|
|
|
[← Wiki index](../../index.md)
|
|
|
|
<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->
|