added files

2026-08-26 02:02:24 +05:30
parent 58ee8a276a
commit 3419cfba0c
200 changed files with 22132 additions and 0 deletions
@@ -0,0 +1,66 @@
+# ADR-0011: Build-user identity routes post-build callbacks
+
+**Status:** Accepted
+**Category:** COMMUNICATION
+**Date decided:** Early on
+**Date documented:** 2026-05-13
+
+## Context
+
+Once a build completes, the pipeline must (a) notify the service team, and (b) tell the deployment-orchestration layer that a new image is ready to roll out. Multiple orchestrators consume this signal — Ringmaster and Turbo-Turtle (the actively maintained CD systems), the legacy Deployment Tracker (still backing some downstream tooling), and a toolchain-environment build-callback service used by Node toolchain builds. Each consumer has a different API contract, a different Slack message shape, and a different policy on whether the team channel should be notified at all. The shared library is invoked by both bot-driven CD (Ringmaster / Turbo-Turtle trigger builds via dedicated bot users) and human-driven Jenkins runs (manual deploys, hotfixes, retries by anyone with allowedUsers), so there is no single contract that fits all callers.
+
+## Decision
+
+`notify.groovy` routes by the Jenkins `build_user`, which is set by whoever triggered the build:
+
+- `build_user == "ringmaster-bot"` or `"turbo-turtle"` → call `deployRingmaster.run()` and emit a Ringmaster-flavored Slack message (production gets a richer message with the deploy URL); the generic team notification is suppressed.
+- Any other user (manual deploy, hotfix, retry) → fall through to a generic `slackSend` on the team's notify channel.
+- `INFRA_ENV == 'toolchain'` → take a completely separate path that POSTs to the toolchain build-callback service and returns early, bypassing the build-user routing entirely.
+
+In parallel, for release branches (`gcp-main` / `main` / `gcp-master` / `master` / `farmiso-main`), the legacy Deployment Tracker (`postTrackingApi`) is always called, and the Ringmaster history-DB (`postTrackingRingmasterApi`) is called when `env.SERVICES` is set.
+
+## Alternatives Considered
+
+No alternatives were explicitly evaluated during this interview. Routing on `build_user` was chosen because it is the only signal available without coordinating an extra config flag with every consumer service.
+
+## Consequences
+
+**Positive:**
+- New consumers can plug in without re-wiring every consumer service's `config.yaml` — they only need to claim a dedicated bot identity.
+- The legacy Deployment Tracker path stays intact for backward compatibility while new traffic flows through Ringmaster.
+- Manual / human-triggered builds get the generic Slack notification path so engineers always see a team-channel message regardless of CD orchestrator.
+
+**Negative:**
+- The routing is implicit and not documented in `config.yaml` — a reader of a service's pipeline cannot tell which CD orchestrator will get the callback without grepping `notify.groovy`.
+- Renaming or replacing either bot identity is breaking: the strings `"ringmaster-bot"` and `"turbo-turtle"` are hard-coded compare targets (the existing `NEVER DO` list in `CLAUDE.md` calls this out for `ringmaster-bot`).
+
+**Neutral:**
+- The `INFRA_ENV == 'toolchain'` branch sits outside the build-user routing — it is a parallel routing axis (build environment, not trigger identity).
+
+## Constraints
+
+- Caller identity is the only signal available at notify time — no config flag is in scope.
+- Strict string comparison on bot usernames couples this code to Ringmaster / Turbo-Turtle naming.
+
+## Current Assessment
+
+- **Adequate with caveats** — the routing works and survives new CD orchestrators being added, but the dispatch should ideally be table-driven rather than chained `if`s, and the bot-name strings should be configurable rather than hard-coded.
+
+## Related Decisions
+
+- [ADR-0006: Ringmaster as Mandatory Build Trigger Gate](0006-ringmaster-mandatory-build-trigger-gate.md) — Ringmaster also gates the *trigger* side of builds; this ADR covers the *callback* side.
+- [ADR-0007: GitOps Deployments via Strict 4-Step ArgoCD Sync Sequence](0007-gitops-via-argocd-4-step-sync-sequence.md) — the deploy mechanism that Ringmaster invokes downstream.
+
+## Notes
+
+- Key files: `src/com/meesho/stages/notify.groovy`, `src/com/meesho/stages/deployRingmaster.groovy`
+- The release-branch dual-write (`postTrackingApi` + `postTrackingRingmasterApi`) coexists with the build-user routing but is orthogonal to it (gated on `BRANCH_NAME` and `env.SERVICES`).
+- Discovery id: COMMUNICATION-1
+
+<!-- adr-generator-meta
+discovery_id: COMMUNICATION-1
+run_id: 90b9a400-266c-4786-b793-d811efa99276
+last_completed_at: 2026-05-13T12:15:00Z
+mode: create
+cache_uri: gs://ai-blitz-agent-readability/adr/devops-lib/adr-discovery.json
+-->