Commit Graph

20 Commits

Author SHA1 Message Date
71460215d3 cli-plugins/manager: deprecate "IsNotFound"
These errors satisfy errdefs.IsNotFound, so make it a wrapper, and
deprecate it.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-08-04 11:06:49 +02:00
644dc16b16 vendor: github.com/docker/docker master (v29.0-dev)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-07-21 23:04:50 +02:00
4665398a06 vendor: github.com/docker/docker 7937f0846c13 (master, v28.x dev)
full diff: 4b9f0707a0...7937f0846c

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-05-19 14:07:50 +02:00
adb0abaec5 add top-level "docker bake" command as alias for "docker buildx bake"
The [`docker buildx bake`][1] command has reached GA; this patch adds
a top-level `docker bake` command as alias for `docker buildx bake` to
improve discoverability and make it more convenient to use.

With this patch:

    docker --help

    Usage:  docker [OPTIONS] COMMAND

    A self-sufficient runtime for containers

    Common Commands:
      run         Create and run a new container from an image
      exec        Execute a command in a running container
      ps          List containers
      build       Build an image from a Dockerfile
      bake        Build from a file
      pull        Download an image from a registry
      push        Upload an image to a registry
      images      List images
    ...

The command is hidden if buildx is not installed;

    docker --help
    Usage:  docker [OPTIONS] COMMAND

    A self-sufficient runtime for containers

    Common Commands:
      run         Create and run a new container from an image
      exec        Execute a command in a running container
      ps          List containers
      build       Build an image from a Dockerfile
      pull        Download an image from a registry
      push        Upload an image to a registry
      images      List images
    ...

We can do some tweaking after this; currently it show an error
in situations where buildx is missing. We don't account for
"DOCKER_BUILDKIT=0", because this is a new feature that requires
buildx, and cannot be "disabled";

buildx missing;

    docker bake
    ERROR: bake requires the buildx component but it is missing or broken.
           Install the buildx component to use bake:
           https://docs.docker.com/go/buildx/

BuildKit disabled:

    DOCKER_BUILDKIT=0 docker bake
    ERROR: bake requires the buildx component but it is missing or broken.
           Install the buildx component to use bake:
           https://docs.docker.com/go/buildx/

[1]: https://www.docker.com/blog/ga-launch-docker-bake/

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-04-11 16:28:47 +02:00
082dfb7360 cmd/dockerd: use stdlib errors
This package is not imported externally, and we don't need the added
functionality of pkg/errors here, so use stdlib errors.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-03-19 14:04:44 +01:00
a5ec6c2963 cli/command: remove StringSliceReplaceAt utility
It was only used internally in cmd/docker and has no known external
consumers. Move it to cmd/docker and un-export it.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-03-09 22:22:29 +01:00
292713c887 move cli-plugins annotation consts to a separate package
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2025-03-07 12:46:11 +01:00
e5d26a8d40 build: allow BuildKit to be used on Windows daemons that advertise it
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>
2024-06-20 02:49:22 +02:00
9392831817 builder: correct the command path for docker build
The command path sent for `docker build` should be `docker` rather than
`docker build` to be consistent with the other command paths.

* `docker buildx build` has a command path of `docker buildx`
* `docker builder build` has a command path of `docker builder`
* `docker image build` has a command path of `docker image`

The reason this gets set to `docker buildx` rather than `docker buildx
build` is because the `build` portion of the command path is processed
by the plugin. So the command path only contains the portions of the
command path that were processed by this tool.

Since the `build` of `docker build` gets forwarded to `buildx`, it is
not included in the command path.

Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
2024-03-15 11:36:38 -05:00
85dcacd78f plugins: set OTEL_RESOURCE_ATTRIBUTES when invoking a plugin
When a plugin is invoked, the docker cli will now set
`OTEL_RESOURCE_ATTRIBUTES` to pass OTEL resource attribute names to the
plugin as additional resource attributes. At the moment, the only
resource attribute passed is `cobra.command_path`.

All resource attributes passed by the CLI are prepended with the
namespace `docker.cli` to avoid clashing with existing ones the plugin
uses or ones defined by the user.

For aliased commands like the various builder commands, the command path
is overwritten to match with the original name (such as `docker
builder`) instead of the forwarded name (such as `docker buildx build`).

Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
2024-02-28 12:43:05 -08:00
ff7f76af7a Handle empty DOCKER_BUILDKIT like unset
This fixes the cli erroring out if the variable is set to an empty
value.

```
$ export DOCKER_BUILDKIT=
$ docker version
DOCKER_BUILDKIT environment variable expects boolean value: strconv.ParseBool: parsing "": invalid syntax
```

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
2023-04-19 14:17:01 +02:00
06eba426d7 cmd/docker: fix typo in deprecation warning
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-12-19 13:03:28 +01:00
60d62fb729 cmd/docker: improve error message if BUILDKIT_ENABLED=0
Before this change, the error would suggest installing buildx:

    echo "FROM scratch" | DOCKER_BUILDKIT=0  docker build -
    DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
                Install the buildx component to build images with BuildKit:
                https://docs.docker.com/go/buildx/

    ...

However, this error would also be shown if buildx is actually installed,
but disabled through "DOCKER_BUILDKIT=0";

    docker buildx version
    github.com/docker/buildx v0.9.1 ed00243

With this patch, it reports that it's disabled, and how to fix:

    echo "FROM scratch" | DOCKER_BUILDKIT=0  docker build -
    DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
                BuildKit is currently disabled; enabled it by removing the DOCKER_BUILDKIT=0
                environment-variable.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-12-09 13:08:07 +01:00
997846918e build: keep "buildx install" behavior
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-11-04 08:42:34 +01:00
d1cabdff99 build: set default context builder if not specified
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-11-04 08:42:34 +01:00
e7a8748b93 build: use legacy builder for wcow if not opt-in with a builder component
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-24 17:57:56 +01:00
16edf8bffb builder: conditional warning for wcow
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-03 19:15:58 +01:00
bce65f0edc builder: simplify error generation, and rephrase error/warning
With this change:

    echo 'FROM busybox' | DOCKER_BUILDKIT=1 docker build -
    ERROR: BuildKit is enabled but the buildx component is missing or broken.
           Install the buildx component to build images with BuildKit:
           https://docs.docker.com/go/buildx/

    echo 'FROM busybox' | docker build -
    DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
                Install the buildx component to build images with BuildKit:
                https://docs.docker.com/go/buildx/

    Sending build context to Docker daemon  2.048kB
    ...

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-02-03 10:38:05 +01:00
4d8e45782b builder: fallback to legacy
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-03 10:38:05 +01:00
6fef143dbc Set buildx as default builder
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-03 10:38:05 +01:00