- Shipped
- September 8, 2026 at 2:51 PM UTC
- Author
- Kamo
- Commit
- 6852acb
Rebuilding this service without a commit of its own — a workflow_dispatch, a re-run, or a kamo-shared-library change it must pick up — has been failing at deploy_k1m1 for at least the last two attempts (#673 and #674). The guard was there and was defeated by the step above it. It compared the image reference before and after `set image`, on the reasoning that a same-commit rebuild produces an identical reference and therefore a silent no-op. But "Apply manifests" runs `kubectl apply -f k8s/deployment.yaml`, whose image is `:latest` — so `before` is ALWAYS `:latest` and `after` is ALWAYS the SHA. They differ on every single run, including the one case the check exists for. The consequence was not a false green. It was worse in a more useful way: the restart never fired, the pre-existing SHA ReplicaSet was already Available, so `rollout status` returned instantly against 13-hour-old pods, and the digest verification correctly failed the job with no obvious cause. The digest is the only thing that can tell a fresh image from a stale one — which the comment already said — so ask it directly instead of inferring from a reference two steps have written to. `rollout status` moves above the check so there are pods to read a digest from. Found while rebuilding this service to pick up ServiceType.HOLDEM, which is what the Apps & Features catalogue and every permission editor read from its jar. That rollout was completed by hand in the meantime.