Commit Graph
9 Commits
Author SHA1 Message Date
meda 2cf8a44f05 Add renovate.json 2026-09-02 00:05:52 +00:00
meda 8d5336b8fd fix: remove cleanup stop step — composite actions run inline, stopping buildkitd before the build
The 'Stop BuildKit (idle cleanup)' step executed immediately after setup
(composite action steps are not deferred to job end; always() does not
create a post-step), so every downstream buildx build failed with
'waiting for connection: context deadline exceeded'.
v1
2026-09-01 14:15:36 +02:00
meda d606ea669d revert: restore loopback endpoint — executor really runs network=host
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.
2026-09-01 13:49:27 +02:00
meda bb2de12bae fix: use container DNS name endpoint, executor runs on same docker network
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).
2026-09-01 13:40:02 +02:00
meda 7841e69c38 fix: recreate buildkitd when not running (config drift)
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.
2026-09-01 13:29:26 +02:00
meda 7c97a428ae fix: publish buildkitd port to host loopback, endpoint tcp://127.0.0.1
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.
2026-09-01 13:25:02 +02:00
meda 5969123c2e fix: buildkitd network + TCP listener for remote driver
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.
2026-09-01 13:12:43 +02:00
meda cc86811f6d mod: default cleanup=true 2026-09-01 11:54:03 +02:00
meda 69d77d4ca0 feat: composite action for labeled buildkitd + remote buildx driver
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>.
2026-09-01 11:52:19 +02:00