Skip to content

build: don't hardcode classic builder for windows daemons #5001

@thaJeztah

Description

@thaJeztah

Description

relates to:

When support for BuildKit was removed from the CLI (using Buildx instead), we implemented logic to detect whether BuildKit or the classic builder should be used. As Windows did not support BuildKit, the CLI was hard-coded to use the classic builder in Windows binaries (with an option to force using buildx when using docker buildx install).

While current versions of the Docker Engine do not yet support BuildKit on Windows, work is in progress to add support for it, and BuildKit 0.13 has experimental support for Windows.

The daemon provides a BuilderVersion field as part of the /_ping response to advertise the suggested version of the Builder to use. Currently that is 2 (BuildKit) on Linux, and 1 (classic builder) on Windows;

curl -I --unix-socket /var/run/docker.sock http://localhost/_ping
HTTP/1.1 200 OK
Api-Version: 1.45
Builder-Version: 2
Cache-Control: no-cache, no-store, must-revalidate
Content-Type: text/plain; charset=utf-8
Date: Wed, 10 Apr 2024 09:11:20 GMT
Docker-Experimental: false
Ostype: linux
Pragma: no-cache
Server: Docker/26.0.0 (linux)
Swarm: active/manager

While that information must be considered a recommendation (the client is still allowed to opt-in/opt-out), we should use this information as part of the logic in the CLI to decide whether BuildKit or the legacy builder should be used, so that the CLI can be used with a Windows daemon that has experimental support for BuildKit enabled would automatically use BuildKit without changes in the CLI's configuration.

Note that, for this to be functional, a Windows Buildx binary (CLI-plugin) must be present; similar to how this is needed on Linux.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions