Deploy Request
The workflow view shows that a deploy happens. This one shows what it does — the actual call sequence between merging and serving traffic. It is the view worth having open when a rollout is stuck, because each stall has a distinct signature.
The digest is the contract
Notice what the controller asks the registry for: it resolves a digest, not a tag.
A tag is a mutable pointer. service:latest means something different depending on when
you ask, which makes “the same version” an unverifiable claim. A digest is the
content hash of the image — it cannot drift, and two environments running the same
digest are provably running the same bytes.
Three consequences follow, and they are the reason the whole platform is built this way:
- Nothing is rebuilt between staging and production. The artifact that soaked is the artifact that ships.
- A revert is a digest restore. No build, no CI run — which is why it takes seconds.
- Provenance is checkable. Admission can verify that this specific digest was signed by this specific pipeline from this specific commit.
Reading a stalled rollout
Find the last message that completed, and the failure is almost always in the next hop.
| Last completed | Likely cause | Where to look |
|---|---|---|
request rollout | The digest never reached the registry | The CI run’s push step — did the build actually publish? |
resolve digest | Tag/digest mismatch, or the wrong environment was targeted | The controller’s release record |
submit workload → no verdict | Signing, provenance, or policy is missing | Admission controller logs; see supply-chain policy |
policy verdict → nothing applied | The cluster cannot schedule the workload | Pod events: capacity, quotas, node selectors |
apply canary 1% → no scale-up | Probes are failing, or the SLO window has not closed | Your service’s readiness endpoint and its error rate |
That last row is the one most often misread as a broken pipeline. A canary sitting at 1% with healthy probes is usually not stuck at all — the controller is waiting for enough traffic to make a statistically meaningful judgement. Check the configured soak window before escalating.
Why the controller stays activated throughout
In the diagram, the controller’s activation bar spans nearly the whole sequence while every other participant’s is short. That asymmetry is the design: one component holds the release state and makes every promotion decision. The registry, admission controller, cluster, and probes are all asked, and each answers a narrow question.
When you need to know the current state of a release, ask the controller. The other components only know about the moment they were consulted.