GH Actions runners Docker shenanigans

[tgeoghegan]

We have experience some churn in our usage of Docker in GitHub Actions lately. This account of events is based on my memory and thus possibly incomplete or wrong.

• Docker v29 is released. Presumably there is a corresponding release of docker-buildx, which is versioned and released separately. Something changes in the release about the layout of metadata JSON emitted by docker buildx.
• February 9ish: GitHub updates Docker in the ubuntu-latest GH runner image to v29.1.* ([Windows/Ubuntu] Docker Server and Client will be updated to version 29.1.*, Docker Compose will be updated to version 2.40.3 on February 9th, 2026 actions/runner-images#13474).
• Janus CI jobs start failing.
• Janus takes a change to look for image SHAs in a new location (Revert _and_ Bake #4366, release/0.7: fix bake target metadata #4367). CI works again.
• February 19-20ish: GitHub rolls the Docker version on ubuntu-latest back due to people's jobs failing due to some other incompatibility across Docker versions ([Windows/Ubuntu] Docker Server and Client will be updated to version 29.1.*, Docker Compose will be updated to version 2.40.3 on February 9th, 2026 actions/runner-images#13474 (comment)).
• Janus CI breaks again (https://github.com/divviup/janus/actions/runs/22208701146/job/64238533069?pr=4371)
• Since our build tools work with Docker v29.1 and up, we adopt the docker/setup-docker-action action to undo GitHub's rollback (Pin Docker v29.2.1 in CI #4376).

[tgeoghegan]

If #4376 works, we'll want to take the same change on release/0.7.

I pinned Docker in the various ci-build.yml jobs, but not in push-docker-images-release.yml. I'm not sure if that workflow is broken or not. I would think not because it doesn't appear to rely on parsing docker buildx metadata.

We've used the docker/setup-buildx-action for some time now, without pinning a buildx version. I'm slightly concerned about compatibility with between a pinned Docker and arbitrary buildx. The Ubuntu runners come with a current buildx installed, so maybe we can stop installing that if/when GH rolls runners back forward to a Docker version that's OK for us. Or we'd have to commit to pinning versions and then maybe getting dependabot to roll it forward for us.

[tgeoghegan]

Pinning Docker v29.2.1 didn't work. We observed unexplained DNS failures when fetching images from DockerHub that do not reproduce with Docker v28.

[tgeoghegan]

Pinning Docker v28.5.2 also didn't work. My guess at this point is that the Docker preinstalled into GH Runner images and the Docker installed by setup-docker-action are different in some regard -- perhaps one disables CGO or otherwise provides its own DNS resolver?