Preventive: this repo carries the workflow that stranded bennett-portfolio.
The bug
The runner builds on the host's Docker daemon — the same daemon the live containers run on — so docker build -t …:latestis a deployment. Watchtower compares the running container against :latest, sees a difference, and recreates it from the locally built image. Gating only the push on != 'pull_request' never helped: the build was the deploy.
The quieter failure is the damaging one. Reassigning :latest leaves the running container's old image untagged; once pruned, Watchtower cannot read it to compare against and gives up every cycle:
warning: Failed to retrieve container image info: No such image: sha256:…
info : Unable to update container: no available image info.
bennett-portfolio hit this on 27 Jul — a four-day-old build, 720 failed update attempts in 24 hours, healthy throughout, no alarm anywhere. It had to be recreated by hand.
The fix
A PR builds pr-<number>, which nothing watches. Same change itsthevine and bennett-portfolio now carry. Trivy still scans whatever was built, so a broken Dockerfile or new HIGH/CRITICAL CVE still gates the merge; the push step is untouched and still main-only.
Note
This repo is not currently stranded — I checked every running container and only bennett-portfolio was affected. This closes the exposure before it bites.
Preventive: this repo carries the workflow that stranded `bennett-portfolio`.
### The bug
The runner builds on the host's Docker daemon — the same daemon the live containers run on — so `docker build -t …:latest` **is** a deployment. Watchtower compares the running container against `:latest`, sees a difference, and recreates it from the locally built image. Gating only the *push* on `!= 'pull_request'` never helped: the build was the deploy.
The quieter failure is the damaging one. Reassigning `:latest` leaves the running container's old image untagged; once pruned, Watchtower cannot read it to compare against and gives up every cycle:
```
warning: Failed to retrieve container image info: No such image: sha256:…
info : Unable to update container: no available image info.
```
`bennett-portfolio` hit this on 27 Jul — a four-day-old build, **720 failed update attempts in 24 hours**, `healthy` throughout, no alarm anywhere. It had to be recreated by hand.
### The fix
A PR builds `pr-<number>`, which nothing watches. Same change `itsthevine` and `bennett-portfolio` now carry. Trivy still scans whatever was built, so a broken Dockerfile or new HIGH/CRITICAL CVE still gates the merge; the push step is untouched and still main-only.
### Note
This repo is **not** currently stranded — I checked every running container and only `bennett-portfolio` was affected. This closes the exposure before it bites.
Generated with [Claude Code](https://claude.com/claude-code)
This runner builds on the host's Docker daemon — the same daemon the live
container runs on — so retagging :latest IS a deployment. Watchtower compares
the running container's image against :latest, sees they differ, and recreates
the container from whatever was just built locally. Gating only the push was
never enough; the build itself was the deploy.
The worse failure is quieter. Reassigning :latest leaves the running
container's old image untagged, and once that image is pruned Watchtower can no
longer read it to compare against:
Failed to retrieve container image info: No such image: sha256:…
Unable to update container: no available image info.
bennett-portfolio hit exactly that. It sat on a four-day-old build, failing to
update 720 times in twenty-four hours, reporting healthy the whole time, and had
to be recreated by hand. This repo has the same workflow and the same exposure —
it simply has not been unlucky yet.
A PR now builds pr-<number>, which nothing watches. Trivy scans whatever was
built either way, so a bad Dockerfile or a new CVE still blocks the merge, and
the push step is unchanged — still main-only.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
austin
merged commit e643062b17 into main2026-07-27 09:58:25 -05:00
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.
Preventive: this repo carries the workflow that stranded
bennett-portfolio.The bug
The runner builds on the host's Docker daemon — the same daemon the live containers run on — so
docker build -t …:latestis a deployment. Watchtower compares the running container against:latest, sees a difference, and recreates it from the locally built image. Gating only the push on!= 'pull_request'never helped: the build was the deploy.The quieter failure is the damaging one. Reassigning
:latestleaves the running container's old image untagged; once pruned, Watchtower cannot read it to compare against and gives up every cycle:bennett-portfoliohit this on 27 Jul — a four-day-old build, 720 failed update attempts in 24 hours,healthythroughout, no alarm anywhere. It had to be recreated by hand.The fix
A PR builds
pr-<number>, which nothing watches. Same changeitsthevineandbennett-portfolionow carry. Trivy still scans whatever was built, so a broken Dockerfile or new HIGH/CRITICAL CVE still gates the merge; the push step is untouched and still main-only.Note
This repo is not currently stranded — I checked every running container and only
bennett-portfoliowas affected. This closes the exposure before it bites.Generated with Claude Code