- Shipped
- September 5, 2026 at 3:53 PM UTC
- Author
- Kamo
- Commit
- fac1091
The image is tagged with the commit SHA, so rebuilding the same commit produces an identical image reference. `kubectl set image` then changes nothing, the Deployment is never touched, `rollout status` succeeds instantly against the OLD pods, and the pipeline goes green having deployed nothing. That is not hypothetical and it is not rare: it happens on every workflow_dispatch, every re-run, and — the case that matters — every time a service must be rebuilt to pick up a kamo-shared-library change without a commit of its own. It happened twice today. Both times the deployment's image tag read correctly while the pods ran stale code, which is precisely why nobody notices: the tag everyone checks to confirm a deploy is the one thing guaranteed to look right. So the step now compares the image reference before and after, and when it is unchanged forces a rollout restart to pull the new content behind that tag. Then it proves the outcome by DIGEST rather than by tag, and fails the build if no pod is running the image this run produced. A tag cannot distinguish fresh content from stale; only the digest can. Had this check existed, both of today's silent no-ops would have been build failures instead of discoveries.