Build the image with BuildKit rather than the builder Docker is retiring

"DEPRECATED: The legacy builder is deprecated and will be removed in a future release."
Not a failure — the image was built and the job carried on — but a countdown, and one the
last commit walked straight into: Alpine's docker-cli package does not carry buildx, so
giving the job a working client left it building the old way.

Two packages instead of one now. With the plugin present `docker build` routes through
BuildKit on its own, which also stops the Dockerfile's independent stages being serialised,
so this is slightly faster as well as not deprecated.

buildx is wanted rather than required, and the difference is deliberate. Missing it costs a
warning and a slower build; the image is still correct. So each install branch ends in
`|| true` and the check afterwards reports instead of exiting — a distribution with no
package for it should not be able to turn a release into a red build over a plugin.

The comment above the build step said this job needed "no buildx plugin", which was true
when the build was the only thing being weighed and is not true now. It says what is
actually wanted, and what is still not: no QEMU, no builder instance to create and tear
down, no third-party action to re-pin.

Verified in Alpine containers with the socket mounted, in all three states this can be in:
nothing installed, the client present and buildx missing — which is exactly what produced
the warning — and buildx unavailable with no package manager to fix it, which warns and
exits 0. The API image builds through BuildKit with no deprecation notice.

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

.github/workflows/ci.yml

@@ -351,30 +351,58 @@ jobs:
           SUDO=""
           [ "$(id -u)" -eq 0 ] || SUDO="sudo"
 
-          if command -v docker >/dev/null 2>&1; then
+          if ! command -v docker >/dev/null 2>&1; then
-            docker --version
+            echo "Installing the docker cli"
-            exit 0
+            if command -v apk >/dev/null 2>&1; then
-          fi
+              $SUDO apk add --no-cache docker-cli
-
+            elif command -v apt-get >/dev/null 2>&1; then
-          echo "Installing the docker cli"
+              $SUDO apt-get update -qq
-          if command -v apk >/dev/null 2>&1; then
+              $SUDO apt-get install -y --no-install-recommends docker.io
-            $SUDO apk add --no-cache docker-cli
+            elif command -v dnf >/dev/null 2>&1; then
-          elif command -v apt-get >/dev/null 2>&1; then
+              $SUDO dnf install -y docker-cli
-            $SUDO apt-get update -qq
+            else
-            $SUDO apt-get install -y --no-install-recommends docker.io
+              echo "No apt-get, apk or dnf here, so the docker client cannot be installed from" >&2
-          elif command -v dnf >/dev/null 2>&1; then
+              echo "inside the job. Add it to the runner's image." >&2
-            $SUDO dnf install -y docker-cli
+              exit 1
-          else
+            fi
-            echo "No apt-get, apk or dnf here, so the docker client cannot be installed from" >&2
-            echo "inside the job. Add it to the runner's image." >&2
-            exit 1
           fi
           docker --version
 
+          # buildx after the client, and wanted rather than required. Without the plugin
+          # `docker build` falls back to the legacy builder, which still produces the image
+          # and says on every run that it will not do so forever; with it the same command
+          # routes through BuildKit and the Dockerfile's independent stages stop being
+          # serialised. Alpine's docker-cli package does not carry it, which is why a job
+          # that had just been given a working client still built the deprecated way.
+          #
+          # A distribution with no package for it should get a warning and an image, not a
+          # failed release — so every branch here ends in `|| true` and the check below
+          # reports rather than exits.
+          if ! docker buildx version >/dev/null 2>&1; then
+            echo "Installing buildx"
+            if command -v apk >/dev/null 2>&1; then
+              $SUDO apk add --no-cache docker-cli-buildx || true
+            elif command -v apt-get >/dev/null 2>&1; then
+              $SUDO apt-get update -qq || true
+              $SUDO apt-get install -y --no-install-recommends docker-buildx || true
+            elif command -v dnf >/dev/null 2>&1; then
+              $SUDO dnf install -y docker-buildx || true
+            fi
+          fi
+
+          if docker buildx version >/dev/null 2>&1; then
+            docker buildx version
+          else
+            echo "::warning::buildx is unavailable, so this image was built by the legacy" \
+                 "builder Docker has deprecated. Add a buildx package to the runner image."
+          fi
+
       # No docker/* actions here, deliberately. The build is single-architecture, so it
-      # needs the daemon this runner already has for the Testcontainers suites and nothing
+      # wants the daemon this runner already has, a client, and BuildKit — all of which the
-      # else — no buildx plugin, no QEMU, and no third-party action whose SHA has to be
+      # step above arranges with two packages. What it does not want is QEMU, a builder
-      # audited and re-pinned. Adding linux/arm64 later is where that trade changes.
+      # instance to create and tear down, or a third-party action whose SHA has to be
+      # audited and re-pinned on a schedule. Adding linux/arm64 later is where that trade
+      # changes, and where setup-buildx-action starts earning its place.
       - name: work out the tags
         id: tags
         env: