added files
This commit is contained in:
Your Name
@@ -0,0 +1,58 @@
|
||||
<!-- 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. -->
|
||||
@@ -0,0 +1,56 @@
|
||||
<!-- m-wiki: type=concept slug=ringmaster-integration 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.
|
||||
|
||||
# Ringmaster / Turbo-Turtle Integration
|
||||
|
||||
`deployRingmaster.run()` routes the CI/CD status callback to either Ringmaster or Turbo-Turtle based on which user triggered the build. These are two separate internal systems that track build and deployment state.
|
||||
|
||||
## Where it applies in this repo
|
||||
|
||||
`src/com/meesho/stages/deployRingmaster.groovy:run`
|
||||
|
||||
**Routing decision:**
|
||||
```
|
||||
build_user = getCause(UserIdCause).getUserId()
|
||||
|
||||
if build_user == "ringmaster-bot":
|
||||
POST https://ringmaster-api.meeshogcp.in/api/v1/key/cicd/cd/update
|
||||
(with Authorization: <ringmaster-token> header)
|
||||
payload: hot_fix, job_name, build_no, image, applications, job_status, etc.
|
||||
else (turbo-turtle, or other allowed user):
|
||||
POST http://turbo-turtle.meeshogcp.in/api/v1/ci/jenkins/callback
|
||||
payload: repo_name, source_branch, pull_request_number, env, job_name,
|
||||
sub_job_name, build_number, image_tag, build_detailed_error
|
||||
```
|
||||
|
||||
For `prd`/`int` environments, the base URL is the production Ringmaster API; for `stg`/`ftr`, it uses the admin endpoint.
|
||||
|
||||
The Turbo-Turtle payload is written to a temp file first to avoid shell escaping issues with JSON special characters, then passed to `curl -d @<file>`. The temp file is always deleted in a `finally` block.
|
||||
|
||||
## Why this design
|
||||
|
||||
Ringmaster is the primary orchestration plane for production deployments triggered by human operators via its UI. Turbo-Turtle is the automated CI/CD bot that validates and triggers deployments from PRs. Both need to know when a Jenkins build completes so they can update their state machines.
|
||||
|
||||
The `ringmaster-bot` user identity is the distinguishing signal: builds triggered from Ringmaster's UI arrive in Jenkins with that user ID, while Turbo-Turtle-triggered builds arrive with the `turbo-turtle` user ID. The string `"ringmaster-bot"` is load-bearing — if Ringmaster ever renames its bot user, callbacks silently fall through to the Turbo-Turtle endpoint. Never change this string without coordinating with the Ringmaster team.
|
||||
|
||||
The Turbo-Turtle JSON payload is written to a temp file (`cicd_payload_${BUILD_NUMBER}_${ts}.json`) to avoid shell escaping failures when payload fields contain single quotes, slashes, or error messages with special characters. The temp file is deleted in a `finally` block.
|
||||
|
||||
## Related
|
||||
|
||||
- [Notifications](../10-NOTIFICATIONS.md) — notify.groovy calls deployRingmaster
|
||||
- [Architecture](../01-ARCHITECTURE.md) — allowedUsers list that includes both bot users
|
||||
|
||||
## 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. -->
|
||||
Reference in New Issue
Block a user