jaap-janandClaude Opus 5 5ddbca49d3 Give the image job a docker client to go with the daemon it already had ...

Exit 127, `docker: command not found`, from the build step of the image job. The daemon was
never the problem and never missing: Testcontainers speaks to /var/run/docker.sock from a
.NET library, so every integration suite in the build job had been starting PostgreSQL,
Keycloak and an sshd on this runner while `docker` was not a command on it at all. Having a
socket and having a client are two different things to have, and this runner had one.

It failed late for the same reason it was easy to miss. Node, git, the SDK and the tags all
came up fine, so the job looked healthy right until the line that actually needed the
binary.

The client only. There is a daemon answering on that socket already — installing an engine
would start a second one beside the one in use, which is a worse outcome than the error.

Verified by running this step's own script in an Alpine container with the socket mounted:
it installs docker-cli, the client then reports server 29.6.2 across the socket, and the
API image builds to completion from inside that container with the repository as its
context. Which is as close to the runner as this can be checked without being it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-01 15:14:28 +02:00

..

workflows

Give the image job a docker client to go with the daemon it already had

2026-08-01 15:14:28 +02:00