CI/CD Pipelines

The CI/CD integration is a thin client, not a separate runtime. A GitHub Actions, GitLab CI, Azure Pipelines, or Jenkins step calls the Magellan API with two inputs: the target environment identifier (`dev`, `staging`, `prod-us-east-1`) and the artifact path in the repo. The API responds with the pinned mapping ULID for that environment and the expected SHA-256.

The CI step computes the SHA-256 of the committed artifact and compares it to the expected hash. A mismatch fails the build with a structured error pointing at the offending file, the expected `ApproverReleaseSigned` ULID, and the actor identity recorded against that release. The failure is informative, not a generic 'check failed' — a developer sees exactly which signed Magellan decision their commit is inconsistent with.

Promotion between environments is controlled by Magellan, not by CI. Moving a pinned mapping from `staging` to `prod` writes `ReleasePromoted` to the ledger carrying the prior pin ULID, the new pin ULID, the actor's role at time of action, and the environment identifier. A CI step that tries to deploy a hash that does not match the current production pin is rejected at the API layer before the build proceeds, not after.

Quality gates from CI/CD & Automation — completeness, validation rule compliance, impact analysis sign-off — run server-side against the candidate mapping ULID and write `QualityGateEvaluated` entries with pass/fail per gate. A failed gate is a ledger entry, not just a build log line, which is what allows a SOX §404 walkthrough to reconstruct why a specific promotion was blocked six months later.

The CI/CD integration is intentionally read-only against the ledger. A failing CI build cannot retry by 'fixing' the ledger; the only path forward is for an Approver to release a new mapping version under role-at-time-of-action RBAC and for the CI step to re-pin against the new ULID. This is what enforces the four-eyes control end-to-end through deployment, not just up to the moment of approval.

All three properties — hash-equality on commit, server-side promotion control, server-side quality gates — combine to make the CI/CD layer the enforcement point for the Why Three Roles Aren't Enough RBAC model. The role split that exists in the Magellan UI is the same role split that decides whether a deployment may proceed in production.