The DaemonSet from #852 is live and failing: Init:Error, /bin/sh: kubectl: not found.
What happened
The merge build pushed sha256:3bc85006… for bird:2026-09-16. Every pod resolved that tag to sha256:75e19214… — the first build of the same day, from before kubectl was added.
imagePullPolicy: Always does not help. It re-pulls, but the tag itself resolves to the stale digest. Evidence:
three pods, three nodes, 2–3 restarts each: all 75e19214
deleted all three; the fresh ones resolved to 75e19214 again
a one-off pod pulling @sha256:3bc85006… directly ran kubectl v1.33.1 and BIRD 2.17.2
So the registry holds the right image; only tag resolution is stale.
Why the dated tag cannot carry this
TAG=$(date +%Y-%m-%d) is mutable within the day, and this image was rebuilt three times today. Any same-day rebuild produces a tag that some nodes have already resolved.
Referencing the digest makes the deployment deterministic.
The cost, stated
The digest has to be updated whenever the image is rebuilt. The obvious alternative — tagging by commit — does not work for a manifest that lives in the same commit as the build. This is a narrow pin for one image, not a change to the repo's dated-tag convention.
The DaemonSet from #852 is live and failing: `Init:Error`, `/bin/sh: kubectl: not found`.
## What happened
The merge build pushed `sha256:3bc85006…` for `bird:2026-09-16`. Every pod resolved that tag to `sha256:75e19214…` — the **first** build of the same day, from before `kubectl` was added.
`imagePullPolicy: Always` does not help. It re-pulls, but the tag itself resolves to the stale digest. Evidence:
- three pods, three nodes, 2–3 restarts each: all `75e19214`
- deleted all three; the fresh ones resolved to `75e19214` again
- a one-off pod pulling `@sha256:3bc85006…` directly ran `kubectl v1.33.1` and `BIRD 2.17.2`
So the registry holds the right image; only tag resolution is stale.
## Why the dated tag cannot carry this
`TAG=$(date +%Y-%m-%d)` is mutable within the day, and this image was rebuilt three times today. Any same-day rebuild produces a tag that some nodes have already resolved.
Referencing the digest makes the deployment deterministic.
## The cost, stated
The digest has to be updated whenever the image is rebuilt. The obvious alternative — tagging by commit — does not work for a manifest that lives in the same commit as the build. This is a narrow pin for one image, not a change to the repo's dated-tag convention.
Refs #576
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The DaemonSet came up with Init:Error, kubectl: not found. The build had pushed sha256:3bc85006 for bird:2026-09-16, but every pod resolved that tag to sha256:75e19214 — the first build of the same day, from before kubectl was added.
imagePullPolicy: Always does not help: it re-pulls, but the tag itself resolves to the stale digest. Deleting the pods changed nothing; three fresh pods on three nodes all resolved to the old digest. A one-off pod pulling the digest directly ran kubectl 1.33.1 and BIRD 2.17.2, so the registry holds the right image and only tag resolution is stale.
The dated tag cannot carry a same-day rebuild, and this image was rebuilt three times today. Referencing the digest makes the deployment deterministic. The cost is that the reference has to be updated whenever the image is rebuilt; the alternative, tagging by commit, does not work for a manifest living in the same commit.
Refs #576
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The DaemonSet from #852 is live and failing:
Init:Error,/bin/sh: kubectl: not found.What happened
The merge build pushed
sha256:3bc85006…forbird:2026-09-16. Every pod resolved that tag tosha256:75e19214…— the first build of the same day, from beforekubectlwas added.imagePullPolicy: Alwaysdoes not help. It re-pulls, but the tag itself resolves to the stale digest. Evidence:75e1921475e19214again@sha256:3bc85006…directly rankubectl v1.33.1andBIRD 2.17.2So the registry holds the right image; only tag resolution is stale.
Why the dated tag cannot carry this
TAG=$(date +%Y-%m-%d)is mutable within the day, and this image was rebuilt three times today. Any same-day rebuild produces a tag that some nodes have already resolved.Referencing the digest makes the deployment deterministic.
The cost, stated
The digest has to be updated whenever the image is rebuilt. The obvious alternative — tagging by commit — does not work for a manifest that lives in the same commit as the build. This is a narrow pin for one image, not a change to the repo's dated-tag convention.
Refs #576
🤖 Generated with Claude Code