# 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