devops-lib-gcp/docs/adr/0006-ringmaster-mandatory-build-trigger-gate.md

ADR-0006: Ringmaster as Mandatory Build Trigger Gate

Status: Accepted Category: PATTERN Date decided: Early on Date documented: 2026-05-12

Context

Jenkins is accessible to all engineers in the organisation. Without a trigger gate, any engineer can click "Build Now" in Jenkins and kick off a build — including a production deployment — without any audit trail, approval, or callback to downstream systems. Ringmaster is Meesho's internal deployment orchestration system that tracks every deployment: who triggered it, what tag was deployed, when, and whether it succeeded. Turbo-Turtle is the CI callback system that receives the build result and updates deployment state.

Decision

eksCICD.groovy hard-rejects any build not triggered by ringmaster-bot, turbo-turtle, or a hardcoded DevOps allowedUsers list. The rejection is immediate and explicit — the build errors with a message directing the engineer to use Ringmaster instead. The string "ringmaster-bot" is the sole signal that routes CI callbacks correctly between Ringmaster and Turbo-Turtle.

Alternatives Considered

• Allow direct Jenkins triggers with a warning: Rejected — a warning is easily ignored; the deployment would still bypass Ringmaster's tracking and the Turbo-Turtle callback would have no caller to report to.
• Restrict Jenkins UI access via RBAC: Considered but not implemented — coarse-grained Jenkins RBAC would still allow authorized engineers to trigger builds directly, and doesn't solve the callback problem.
• Audit log only (no rejection): Rejected — audit-only does not prevent the problem; it only discovers it after the fact.

Consequences

Positive:

• Every production deployment is tracked in Ringmaster — who triggered it, what tag, when — creating a full deployment ledger.
• Turbo-Turtle always receives the CI result callback because the trigger is always one of the known callers.
• Engineers cannot bypass deployment holds or approval flows by triggering Jenkins directly.

Negative:

• DevOps engineers must maintain the hardcoded allowedUsers list for emergency access (e.g., debugging a pipeline issue directly from Jenkins).
• The gate adds a hard dependency on Ringmaster being operational for any build to run.

Neutral:

• The string "ringmaster-bot" is load-bearing — changing it without coordinating with the Ringmaster team would break the callback routing between Ringmaster and Turbo-Turtle.

Constraints

Meesho's deployment audit and compliance requirements necessitated a full deployment ledger. The Ringmaster/Turbo-Turtle architecture was already in place; the gate was added to enforce its use.

Current Assessment

Still appropriate — no changes needed.

Notes

• Key file: vars/eksCICD.groovy:12-26 — allowedUsers list and trigger validation
• Never change the string "ringmaster-bot" without coordinating with the Ringmaster team — documented in CLAUDE.md under NEVER DO
• Ringmaster UI: https://ringmaster.meeshogcp.in/applications/cicd/home