.github/workflows/release-republish.yml is the manual repair path for a release image — retag a known-good digest, or rebuild from the tag. It handles the manager only. This repo publishes two images.
Why it matters
The failure lands at the worst possible moment. This workflow exists to be reached for during an incident, so a gap in it is not discovered until someone is already repairing a bad release.
Both jobs take a single hardcoded image:
env:
IMAGE: ghcr.io/jacaudi/wireguard-operator/manager rebuild:
uses: ./.github/workflows/ci-build.yml
with:
image: ghcr.io/jacaudi/wireguard-operator/manager
file: images/manager/DockerfileSo there is no supported way to repair ghcr.io/jacaudi/wireguard-operator/agent. That is not hypothetical: the manager's --agent-image default names a versioned agent tag, so a bad or missing agent tag is a broken deployment even when the manager image is perfect.
Why it was left as-is in #43
Three things would each need a second dimension, and none of them is one line:
retag and rebuild both need an image selector threaded through.smoke runs task smoke, which asserts the manager binary specifically — it greps the --help output for -agent-image. Pointed at the agent it would fail, correctly, for the wrong reason.ci-build.yml needs the matching file: per image.
That is real work with no incident asking for it, so #43 recorded the limit in the file instead, with the manual fallback:
docker buildx imagetools create \
-t ghcr.io/jacaudi/wireguard-operator/agent:vX.Y.Z \
ghcr.io/jacaudi/wireguard-operator/agent:sha-<short>
What a fix looks like
Add an image choice input (manager / agent / both) and map it to the name, Dockerfile and smoke behaviour. The smoke half is the part that needs a decision rather than a keystroke: either give task smoke a per-image mode, or skip smoke for the agent and say so explicitly rather than silently.
Worth doing together with, or after, whatever teaches the pipeline to smoke-test the agent at all — ci.yaml's smoke job is manager-only for the same reason, which is the more routine version of this same gap.
.github/workflows/release-republish.ymlis the manual repair path for a release image — retag a known-good digest, or rebuild from the tag. It handles the manager only. This repo publishes two images.Why it matters
The failure lands at the worst possible moment. This workflow exists to be reached for during an incident, so a gap in it is not discovered until someone is already repairing a bad release.
Both jobs take a single hardcoded image:
So there is no supported way to repair
ghcr.io/jacaudi/wireguard-operator/agent. That is not hypothetical: the manager's--agent-imagedefault names a versioned agent tag, so a bad or missing agent tag is a broken deployment even when the manager image is perfect.Why it was left as-is in #43
Three things would each need a second dimension, and none of them is one line:
retagandrebuildboth need an image selector threaded through.smokerunstask smoke, which asserts the manager binary specifically — it greps the--helpoutput for-agent-image. Pointed at the agent it would fail, correctly, for the wrong reason.ci-build.ymlneeds the matchingfile:per image.That is real work with no incident asking for it, so #43 recorded the limit in the file instead, with the manual fallback:
What a fix looks like
Add an
imagechoice input (manager/agent/both) and map it to the name, Dockerfile and smoke behaviour. The smoke half is the part that needs a decision rather than a keystroke: either givetask smokea per-image mode, or skip smoke for the agent and say so explicitly rather than silently.Worth doing together with, or after, whatever teaches the pipeline to smoke-test the agent at all —
ci.yaml'ssmokejob is manager-only for the same reason, which is the more routine version of this same gap.