Commit 6fef143dbc switched the CLI to use
BuildKit by default, but as part of that removed the use of the
BuildkitVersion field as returned by Ping.
Some follow-up changes in commits e38e6c51ff and
e7a8748b93 updated the logic for detecting whether
BuildKit should be used or the legacy builder, but hard-coded using the
legacy builder for Windows daemons.
While Windows / WCOW does not yet support BuildKit by default, there is
work in progress to implement it, so we should not hard-code the assumption
that a Windows daemon cannot support BuildKit.
On the daemon-side, [moby@7b153b9] (Docker v23.0) changed the default as
advertised by the daemon to be BuildKit for Linux daemons. That change
still hardcoded BuildKit to be unsupported for Windows daemons (and does
not yet allow overriding the config), but this may change for future
versions of the daemon, or test-builds.
This patch:
- Re-introduces checks for the BuildkitVersion field in the "Ping" response.
- If the Ping response from the daemon advertises that it supports BuildKit,
the CLI will now use BuildKit as builder.
- If we didn't get a Ping response, or the Ping response did NOT advertise
that the daemon supported BuildKit, we continue to use the current
defaults (BuildKit for Linux daemons, and the legacy builder for Windows)
- Handling of the DOCKER_BUILDKIT environment variable is unchanged; for
CLI.BuildKitEnabled, DOCKER_BUILDKIT always takes precedence, and for
processBuilder the value is taken into account, but will print a warning
when BuildKit is disabled and a Linux daemon is used. For Windows daemons,
no warning is printed.
[moby@7b153b9]: 7b153b9e28
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add some documentation about their purpose, and document order of preference
when resolving plugins.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This file is only used as default if no version is specified. We
should probably get rid of this, but let's update it to better
reflect the version that developer builds are building.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Before this:
make shell
make -C ./internal/gocompat/
...
GO111MODULE=on go test -v
# github.com/docker/cli/cli/command/image
../../cli/command/image/push.go:177:62: predeclared any requires go1.18 or later (-lang was set to go1.16; check go.mod)
FAIL gocompat [build failed]
make: *** [Makefile:3: verify] Error 1
make: Leaving directory '/go/src/github.com/docker/cli/internal/gocompat'
After this patch:
make shell
make -C ./internal/gocompat/
...
GO111MODULE=on go test -v
=== RUN TestModuleCompatibllity
main_test.go:133: all packages have the correct go version specified through //go:build
--- PASS: TestModuleCompatibllity (0.00s)
PASS
ok gocompat 0.007s
make: Leaving directory '/go/src/github.com/docker/cli/internal/gocompat'
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Commit 27b2797f7d added a local implementation
of this function, so let's use the local variant to (slightly) reduce the
dependency on moby's registry package.
Also made some minor cleanups.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Since 509123f935, we've been leaking sockets
in the filesystem on platforms where abstract sockets aren't supported.
That change relied on Go to cleanup our sockets for us, which Go will happily
do as long as we make sure to close the listener, which we weren't previously
doing unless to signal the plugin to terminate.
This change adds a deferred call to `PluginServer.Close()`, which makes sure we
close the plugin server at the end of the plugin execution, so that we never exit
without cleaning up.
Signed-off-by: Laura Brehm <laurabrehm@hey.com>
Sebastiaan van Stijn
Sebastiaan van Stijn
Alano Terblanche
dependabot[bot]
Paweł Gronowski
Laura Brehm