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 ifs, and the bot-name strings should be configurable rather than hard-coded.

ADR-0006: Ringmaster as Mandatory Build Trigger Gate — 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 — 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

4.6 KiB Raw Blame History