17 Commits

Author SHA1 Message Date
Sebastiaan van Stijn
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
Sebastiaan van Stijn
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
Sebastiaan van Stijn
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
Sebastiaan van Stijn
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
Sebastiaan van Stijn
e5d26a8d40
build: allow BuildKit to be used on Windows daemons that advertise it
Commit 6fef143dbcf5fdcb436d05cf8e67d56c24bc4e6e 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 e38e6c51ffb55405321038dfcf3a477f and
e7a8748b939fbf7798352cff1e0b87ef 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
Jonathan A. Sternberg
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
Jonathan A. Sternberg
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
Paweł Gronowski
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
Sebastiaan van Stijn
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
Sebastiaan van Stijn
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
CrazyMax
997846918e
build: keep "buildx install" behavior
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-11-04 08:42:34 +01:00
CrazyMax
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
CrazyMax
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
CrazyMax
16edf8bffb
builder: conditional warning for wcow
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-03 19:15:58 +01:00
Sebastiaan van Stijn
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
CrazyMax
4d8e45782b
builder: fallback to legacy
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-03 10:38:05 +01:00
CrazyMax
6fef143dbc
Set buildx as default builder
Signed-off-by: CrazyMax <crazy-max@users.noreply.github.com>
2022-02-03 10:38:05 +01:00