Job 9024 runner log proves the executor container is created with
network="host", where docker DNS names do not resolve, so
tcp://<name>:<port> cannot connect. Restore tcp://127.0.0.1:<port>
plus the loopback port publish. The failure #4 build-step timeout has
a different (still investigated) cause.
Root cause of the 'waiting for connection' build failure: the act_runner
executor container runs on the same docker network as buildkitd, so its
127.0.0.1 is its own loopback — the host-published port is unreachable
from there. Revert to tcp://<name>:<port>; container DNS resolves on the
shared network. Drop the now-useless loopback port publish.
Verified on host: from a container on that network, endpoint
tcp://<name>:8375 -> 'Status: running'; tcp://127.0.0.1:8375 ->
'ERROR: context deadline exceeded' (exact CI symptom).
The name-exists guard skipped recreation when a stopped container
from a previous failed run existed — e.g. one created before the
port mapping was added, leaving 127.0.0.1:8375 with no listener.
New logic: recreate the container whenever it is not running;
keep it (warm cache) when it is already up.
Second failure mode: act_runner executes job steps in executor
containers running with network=host (despite container.network
config — that only applies to job containers). The buildx CLI
therefore resolves tcp://buildkitd:8375 in the HOST namespace,
where docker DNS names do not resolve.
Fix: publish buildkitd's TCP port to host loopback
(-p 127.0.0.1:8375:8375) and use tcp://127.0.0.1:8375 as the
endpoint. Works from both host-network executors and job
containers; port is not exposed on any external interface.
Validated on oracle: buildx remote Status running,
platforms linux/arm64,v7,v6.
Two bugs made the first CI run fail with 'waiting for connection:
context deadline exceeded':
1. Container started without --network landed on default bridge,
while job containers run on git_default -> name unresolvable,
bridge IP unreachable cross-network.
2. moby/buildkit default entrypoint only listens on a unix socket.
driver: remote needs TCP. Added --addr tcp://0.0.0.0:8375 and
changed endpoint from docker-container://name (only valid for
the docker-container driver) to tcp://name:8375.
Both verified on the oracle host: buildx remote driver connects,
Status running, platforms linux/arm64,v7,v6.
The default docker-container driver of docker/setup-buildx-action ignores
driver-opts labels (container created with labels={}) and the Docker API
cannot PATCH labels on existing containers. Start a privileged, labeled
buildkitd ourselves (idempotent, restart unless-stopped) and connect via
driver: remote endpoint docker-container://<name>.
meda