fail build if minimal required version of buildx isn't installed - #13295
Merged
Merged
Conversation
glours
approved these changes
Oct 18, 2025
Signed-off-by: Nicolas De Loof <nicolas.deloof@gmail.com>
ndeloof
enabled auto-merge (rebase)
October 20, 2025 10:14
ndeloof
force-pushed
the
buildx_minimal_version
branch
from
October 20, 2025 10:14
fb4641f to
a06ba13
Compare
tmeijn
pushed a commit
to tmeijn/dotfiles
that referenced
this pull request
Oct 23, 2025
This MR contains the following updates: | Package | Update | Change | |---|---|---| | [docker/compose](https://github.com/docker/compose) | patch | `v2.40.1` -> `v2.40.2` | MR created with the help of [el-capitano/tools/renovate-bot](https://gitlab.com/el-capitano/tools/renovate-bot). **Proposed changes to behavior should be submitted there as MRs.** --- ### Release Notes <details> <summary>docker/compose (docker/compose)</summary> ### [`v2.40.2`](https://github.com/docker/compose/releases/tag/v2.40.2) [Compare Source](docker/compose@v2.40.1...v2.40.2) #### What's Changed - Compose can't create a tar with adequate uid:gid ownership by [@​ndeloof](https://github.com/ndeloof) in [#​13299](docker/compose#13299) - fail build if minimal required version of buildx isn't installed by [@​ndeloof](https://github.com/ndeloof) in [#​13295](docker/compose#13295) - remove unused code to only rely on api.Service by [@​ndeloof](https://github.com/ndeloof) in [#​13300](docker/compose#13300) - test digest or canonical reference, not only tag, when checking if an image is already present by [@​glours](https://github.com/glours) in [#​13302](docker/compose#13302) - introduce WithPrompt to configure compose backend to use a plugable UI component for user interaction by [@​ndeloof](https://github.com/ndeloof) in [#​13308](docker/compose#13308) **Full Changelog**: <docker/compose@v2.40.1...v2.40.2> </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever MR is behind base branch, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this MR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this MR, check this box --- This MR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0MS4xNTcuMCIsInVwZGF0ZWRJblZlciI6IjQxLjE1Ny4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJSZW5vdmF0ZSBCb3QiXX0=-->
4 tasks
rfay
added a commit
to rfay/ddev
that referenced
this pull request
Feb 16, 2026
- Fixes ddev#8117 Docker Compose now requires the buildx plugin (>= 0.17.0) per docker/compose#13295. DDEV depends on docker-compose and buildx but previously only checked for buildx in the diagnostic `ddev utility dockercheck` command via shell exec, with no version enforcement. - Uses the `docker/cli/cli-plugins/manager` Go package (already a dependency via docker/cli) to discover CLI plugins and their versions via `manager.ListPlugins()`, replacing shell-based detection. - Adds `BuildxVersionConstraint` (">= 0.17.0") to `DockerVersionMatrix`. - Adds `GetBuildxVersion()` and `CheckDockerBuildx()` in requirements.go, following the same pattern as `CheckDockerCompose()`. - Checks buildx at `ddev start`/`ddev restart` time in root.go `PersistentPreRun`. - Shows `docker-buildx` version in `ddev version` output. - Updates `ddev utility dockercheck` to use the new Go-based detection. 1. `ddev version` — should show a `docker-buildx` row with the version 2. `ddev utility dockercheck` — should show buildx version and check result 3. `ddev start` on any project — should pass buildx check silently Added `TestGetCLIPlugins`, `TestGetBuildxVersion`, and `TestCheckBuildx` tests in `pkg/dockerutil/requirements_test.go`. Users without the buildx plugin installed (or with versions < 0.17.0) will see a failure at `ddev start`/`ddev restart` time with install instructions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
rfay
added a commit
to rfay/ddev
that referenced
this pull request
Feb 16, 2026
…skip buildkite] - Fixes ddev#8117 Docker Compose now requires the buildx plugin (>= 0.17.0) per docker/compose#13295. DDEV depends on docker-compose and buildx but previously only checked for buildx in the diagnostic `ddev utility dockercheck` command via shell exec, with no version enforcement. - Uses the `docker/cli/cli-plugins/manager` Go package (already a dependency via docker/cli) to discover CLI plugins and their versions via `manager.ListPlugins()`, replacing shell-based detection. - Adds `BuildxVersionConstraint` (">= 0.17.0") to `DockerVersionMatrix`. - Adds `GetBuildxVersion()` and `CheckDockerBuildx()` in requirements.go, following the same pattern as `CheckDockerCompose()`. - Checks buildx at `ddev start`/`ddev restart` time in root.go `PersistentPreRun`. - Shows `docker-buildx` version in `ddev version` output. - Updates `ddev utility dockercheck` to use the new Go-based detection. 1. `ddev version` — should show a `docker-buildx` row with the version 2. `ddev utility dockercheck` — should show buildx version and check result 3. `ddev start` on any project — should pass buildx check silently Added `TestGetCLIPlugins`, `TestGetBuildxVersion`, and `TestCheckBuildx` tests in `pkg/dockerutil/requirements_test.go`. Users without the buildx plugin installed (or with versions < 0.17.0) will see a failure at `ddev start`/`ddev restart` time with install instructions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
rfay
added a commit
to rfay/ddev
that referenced
this pull request
Feb 17, 2026
…skip buildkite] - Fixes ddev#8117 Docker Compose now requires the buildx plugin (>= 0.17.0) per docker/compose#13295. DDEV depends on docker-compose and buildx but previously only checked for buildx in the diagnostic `ddev utility dockercheck` command via shell exec, with no version enforcement. - Uses the `docker/cli/cli-plugins/manager` Go package (already a dependency via docker/cli) to discover CLI plugins and their versions via `manager.ListPlugins()`, replacing shell-based detection. - Adds `BuildxVersionConstraint` (">= 0.17.0") to `DockerVersionMatrix`. - Adds `GetBuildxVersion()` and `CheckDockerBuildx()` in requirements.go, following the same pattern as `CheckDockerCompose()`. - Checks buildx at `ddev start`/`ddev restart` time in root.go `PersistentPreRun`. - Shows `docker-buildx` version in `ddev version` output. - Updates `ddev utility dockercheck` to use the new Go-based detection. 1. `ddev version` — should show a `docker-buildx` row with the version 2. `ddev utility dockercheck` — should show buildx version and check result 3. `ddev start` on any project — should pass buildx check silently Added `TestGetCLIPlugins`, `TestGetBuildxVersion`, and `TestCheckBuildx` tests in `pkg/dockerutil/requirements_test.go`. Users without the buildx plugin installed (or with versions < 0.17.0) will see a failure at `ddev start`/`ddev restart` time with install instructions. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This was referenced Jul 25, 2026
acoseac
added a commit
to acoseac/1-bit-bridge
that referenced
this pull request
Sep 23, 2026
Round-1 review. The compose paragraph offered `docker compose build` as a route around a missing plugin. It does get through today (measured on 2.40.3, and upstream's buildWithBake returns false on a not-found plugin), but that is a deprecated internal builder, and a buildx older than 0.17 makes Compose refuse outright, so the docs now say not to rely on it. The review's claim that Compose >= 2.40.2 fails when buildx is MISSING misreads docker/compose#13295: its 0.17 check runs only on the Bake path, i.e. when buildx is present. The multi-arch line gains its build context, a tag, and where the result goes (--push, or --load with the containerd image store). QEMU registration becomes conditional: Docker Desktop emulates out of the box, and on Linux it is needed where the runtime stage fails with `exec format error`, which is what Ubuntu's docker.io did here with no binfmt handlers.
acoseac
added a commit
to acoseac/1-bit-bridge
that referenced
this pull request
Sep 23, 2026
… it (#983) * The Dockerfile says it needs BuildKit when the legacy builder reaches it A plain `docker build .` with Ubuntu's or Debian's own docker.io package, neither of which installs the buildx plugin, falls back to Docker's legacy builder, and that builder leaves BUILDPLATFORM unset. The builder FROM then died with `failed to parse platform : "" is an invalid OS component of ""` and a regex dump, naming neither BuildKit nor buildx. `make docker` ran the same plain `docker build`. The FROM now reads ${BUILDPLATFORM:-this-Dockerfile-requires-BuildKit--build-with-docker-buildx}. BuildKit always sets BUILDPLATFORM, so there the fallback is never read: the amd64 and cross-compiled arm64 binaries are byte-identical to main's, and `docker buildx build --check` is clean. On the legacy builder the fallback is the error text. Letting the legacy builder through was measured and refused: - `ARG BUILDPLATFORM=<default>` above the FROM. Under BuildKit a declared default REPLACES the automatic value (`ARG BUILDPLATFORM=linux/s390x` echoes linux/s390x), so it would push every arm64 build host's Go compile under QEMU, the cost the pin exists to avoid. - `${BUILDPLATFORM:-linux}`. It built a working image on the legacy builder (amd64), and was refused as a second build path that no CI runs, for a builder Docker has deprecated. ARG TARGETOS loses its `=linux` default. Its comment claimed the default kept a non-BuildKit build working, which it never did: since #451 the FROM failed first. It also claimed BuildKit overrides the default per target, which is false for the same reason as above. Removing it changes nothing BuildKit executes (`GOOS=linux` either way, identical binaries). `make docker` now runs `docker buildx build --load` behind a check-buildx guard. docs/docker.md gets the install line per distro, what DOCKER_BUILDKIT=1 and `docker compose build` actually do without the plugin, and the QEMU note for multi-arch. It also stops understating the ffmpeg decoder assertion, which covers all four dsd_* decoders plus dst. The rule is in CLAUDE.md, the record in ops/engineering-log.md. * Name PR #983 in the rule and the log entry * Qualify the compose fallback and complete the multi-arch command Round-1 review. The compose paragraph offered `docker compose build` as a route around a missing plugin. It does get through today (measured on 2.40.3, and upstream's buildWithBake returns false on a not-found plugin), but that is a deprecated internal builder, and a buildx older than 0.17 makes Compose refuse outright, so the docs now say not to rely on it. The review's claim that Compose >= 2.40.2 fails when buildx is MISSING misreads docker/compose#13295: its 0.17 check runs only on the Bake path, i.e. when buildx is present. The multi-arch line gains its build context, a tag, and where the result goes (--push, or --load with the containerd image store). QEMU registration becomes conditional: Docker Desktop emulates out of the box, and on Linux it is needed where the runtime stage fails with `exec format error`, which is what Ubuntu's docker.io did here with no binfmt handlers. * check-buildx reports its failure on stderr Round-2 review. The guard's two failure lines went to stdout; they are diagnostics, so they now go to stderr (make's own error line already does). Verified both streams: `make check-buildx 2>/dev/null` prints no guard text, `2>&1 >/dev/null` prints both lines. The success line stays on stdout.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What I did
Related issue
see ae3309a#commitcomment-168173048
(not mandatory) A picture of a cute animal, if possible in relation to what you did