vendor: github.com/docker/buildx v0.16.0

Signed-off-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This commit is contained in:
tonistiigi 2024-07-11 18:50:44 +00:00 committed by github-actions[bot]
parent 09d0b9ae61
commit 31fc531db4
6 changed files with 418 additions and 45 deletions

View File

@ -1,6 +1,6 @@
# github.com/moby/moby v27.0.3+incompatible
# github.com/moby/buildkit v0.14.1
# github.com/docker/buildx v0.15.1
# github.com/moby/buildkit v0.15.0
# github.com/docker/buildx v0.16.0
# github.com/docker/cli v27.0.3+incompatible
# github.com/docker/compose/v2 v2.28.1
# github.com/docker/scout-cli v1.10.0

View File

@ -17,6 +17,27 @@ usage: docker buildx bake [OPTIONS] [TARGET...]
pname: docker buildx
plink: docker_buildx.yaml
options:
- option: call
value_type: string
default_value: build
description: Set method for evaluating build (`check`, `outline`, `targets`)
details_url: '#call'
deprecated: false
hidden: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: check
value_type: bool
description: Shorthand for `--call=check`
details_url: '#check'
deprecated: false
hidden: false
experimental: false
experimentalcli: false
kubernetes: false
swarm: false
- option: file
shorthand: f
value_type: stringArray
@ -29,6 +50,26 @@ options:
experimentalcli: false
kubernetes: false
swarm: false
- option: list-targets
value_type: bool
default_value: "false"
description: List available targets
deprecated: false
hidden: true
experimental: false
experimentalcli: true
kubernetes: false
swarm: false
- option: list-variables
value_type: bool
default_value: "false"
description: List defined variables
deprecated: false
hidden: true
experimental: false
experimentalcli: true
kubernetes: false
swarm: false
- option: load
value_type: bool
default_value: "false"
@ -151,6 +192,14 @@ examples: |-
Same as [`buildx --builder`](/reference/cli/docker/buildx/#builder).
### Invoke a frontend method (--call) {#call}
Same as [`build --call`](/reference/cli/docker/buildx/build/#call).
#### Call: check (--check) {#check}
Same as [`build --check`](/reference/cli/docker/buildx/build/#check).
### Specify a build definition file (-f, --file) {#file}
Use the `-f` / `--file` option to specify the build definition file to use.
@ -219,6 +268,7 @@ examples: |-
```json
{
"buildx.build.warnings": {},
"db": {
"buildx.build.provenance": {},
"buildx.build.ref": "mybuilder/mybuilder0/0fjb6ubs52xx3vygf6fgdl611",
@ -261,6 +311,12 @@ examples: |-
> * `max` sets full provenance.
> * `disabled`, `false` or `0` does not set any provenance.
> **Note**
>
> Build warnings (`buildx.build.warnings`) are not included by default. Set the
> `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
> include them.
### Don't use cache when building the image (--no-cache) {#no-cache}
Same as `build --no-cache`. Don't use cache when building the image.

View File

@ -1,13 +1,7 @@
command: docker buildx build
aliases: docker buildx build, docker buildx b
aliases: docker build, docker builder build, docker image build, docker buildx b
short: Start a build
long: |-
The `buildx build` command starts a build using BuildKit. This command is similar
to the UI of `docker build` command and takes the same flags and arguments.
For documentation on most of these flags, refer to the [`docker build`
documentation](/reference/cli/docker/image/build/).
This page describes a subset of the new flags.
long: The `docker buildx build` command starts a build using BuildKit.
usage: docker buildx build [OPTIONS] PATH | URL | -
pname: docker buildx
plink: docker_buildx.yaml
@ -16,7 +10,7 @@ options:
value_type: stringSlice
default_value: '[]'
description: 'Add a custom host-to-IP mapping (format: `host:ip`)'
details_url: /reference/cli/docker/image/build/#add-host
details_url: '#add-host'
deprecated: false
hidden: false
experimental: false
@ -107,6 +101,7 @@ options:
value_type: string
default_value: build
description: Set method for evaluating build (`check`, `outline`, `targets`)
details_url: '#call'
deprecated: false
hidden: false
experimental: false
@ -116,7 +111,7 @@ options:
- option: cgroup-parent
value_type: string
description: Set the parent cgroup for the `RUN` instructions during build
details_url: /reference/cli/docker/image/build/#cgroup-parent
details_url: '#cgroup-parent'
deprecated: false
hidden: false
experimental: false
@ -126,6 +121,7 @@ options:
- option: check
value_type: bool
description: Shorthand for `--call=check`
details_url: '#check'
deprecated: false
hidden: false
experimental: false
@ -205,7 +201,7 @@ options:
shorthand: f
value_type: string
description: 'Name of the Dockerfile (default: `PATH/Dockerfile`)'
details_url: /reference/cli/docker/image/build/#file
details_url: '#file'
deprecated: false
hidden: false
experimental: false
@ -295,6 +291,7 @@ options:
value_type: string
default_value: default
description: Set the networking mode for the `RUN` instructions during build
details_url: '#network'
deprecated: false
hidden: false
experimental: false
@ -507,7 +504,7 @@ options:
value_type: stringArray
default_value: '[]'
description: 'Name and optionally a tag (format: `name:tag`)'
details_url: /reference/cli/docker/image/build/#tag
details_url: '#tag'
deprecated: false
hidden: false
experimental: false
@ -517,7 +514,7 @@ options:
- option: target
value_type: string
description: Set the target build stage to build
details_url: /reference/cli/docker/image/build/#target
details_url: '#target'
deprecated: false
hidden: false
experimental: false
@ -547,6 +544,32 @@ inherited_options:
kubernetes: false
swarm: false
examples: |-
### Add entries to container hosts file (--add-host) {#add-host}
You can add other hosts into a build container's `/etc/hosts` file by using one
or more `--add-host` flags. This example adds static addresses for hosts named
`my-hostname` and `my_hostname_v6`:
```console
$ docker buildx build --add-host my_hostname=8.8.8.8 --add-host my_hostname_v6=2001:4860:4860::8888 .
```
If you need your build to connect to services running on the host, you can use
the special `host-gateway` value for `--add-host`. In the following example,
build containers resolve `host.docker.internal` to the host's gateway IP.
```console
$ docker buildx build --add-host host.docker.internal=host-gateway .
```
You can wrap an IPv6 address in square brackets.
`=` and `:` are both valid separators.
Both formats in the following example are valid:
```console
$ docker buildx build --add-host my-hostname:10.180.0.1 --add-host my-hostname_v6=[2001:4860:4860::8888] .
```
### Create annotations (--annotation) {#annotation}
```text
@ -642,7 +665,40 @@ examples: |-
### Set build-time variables (--build-arg) {#build-arg}
Same as [`docker build` command](/reference/cli/docker/image/build/#build-arg).
You can use `ENV` instructions in a Dockerfile to define variable values. These
values persist in the built image. Often persistence isn't what you want. Users
want to specify variables differently depending on which host they build an
image on.
A good example is `http_proxy` or source versions for pulling intermediate
files. The `ARG` instruction lets Dockerfile authors define values that users
can set at build-time using the `--build-arg` flag:
```console
$ docker buildx build --build-arg HTTP_PROXY=http://10.20.30.2:1234 --build-arg FTP_PROXY=http://40.50.60.5:4567 .
```
This flag allows you to pass the build-time variables that are
accessed like regular environment variables in the `RUN` instruction of the
Dockerfile. These values don't persist in the intermediate or final images
like `ENV` values do. You must add `--build-arg` for each build argument.
Using this flag doesn't alter the output you see when the build process echoes the`ARG` lines from the
Dockerfile.
For detailed information on using `ARG` and `ENV` instructions, see the
[Dockerfile reference](/reference/dockerfile/).
You can also use the `--build-arg` flag without a value, in which case the daemon
propagates the value from the local environment into the Docker container it's building:
```console
$ export HTTP_PROXY=http://10.20.30.2:1234
$ docker buildx build --build-arg HTTP_PROXY .
```
This example is similar to how `docker run -e` works. Refer to the [`docker run` documentation](/reference/cli/docker/container/run/#env)
for more information.
There are also useful built-in build arguments, such as:
@ -748,6 +804,167 @@ examples: |-
More info about cache exporters and available attributes: https://github.com/moby/buildkit#export-cache
### Invoke a frontend method (--call) {#call}
```text
--call=[build|check|outline|targets]
```
BuildKit frontends can support alternative modes of executions for builds,
using frontend methods. Frontend methods are a way to change or extend the
behavior of a build invocation, which lets you, for example, inspect, validate,
or generate alternative outputs from a build.
The `--call` flag for `docker buildx build` lets you specify the frontend
method that you want to execute. If this flag is unspecified, it defaults to
executing the build and evaluating [build checks](/reference/build-checks/).
For Dockerfiles, the available methods are:
| Command | Description |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| `build` (default) | Execute the build and evaluate build checks for the current build target. |
| `check` | Evaluate build checks for the either the entire Dockerfile or the selected target, without executing a build. |
| `outline` | Show the build arguments that you can set for a target, and their default values. |
| `targets` | List all the build targets in the Dockerfile. |
| `subrequests.describe` | List all the frontend methods that the current frontend supports. |
Note that other frontends may implement these or other methods.
To see the list of available methods for the frontend you're using,
use `--call=subrequests.describe`.
```console
$ docker buildx build -q --call=subrequests.describe .
NAME VERSION DESCRIPTION
outline 1.0.0 List all parameters current build target supports
targets 1.0.0 List all targets current build supports
subrequests.describe 1.0.0 List available subrequest types
```
#### Descriptions
The [`--call=targets`](#call-targets) and [`--call=outline`](#call-outline)
methods include descriptions for build targets and arguments, if available.
Descriptions are generated from comments in the Dockerfile. A comment on the
line before a `FROM` instruction becomes the description of a build target, and
a comment before an `ARG` instruction the description of a build argument. The
comment must lead with the name of the stage or argument, for example:
```dockerfile
# syntax=docker/dockerfile:1
# GO_VERSION sets the Go version for the build
ARG GO_VERSION=1.22
# base-builder is the base stage for building the project
FROM golang:${GO_VERSION} AS base-builder
```
When you run `docker buildx build --call=outline`, the output includes the
descriptions, as follows:
```console
$ docker buildx build -q --call=outline .
TARGET: base-builder
DESCRIPTION: is the base stage for building the project
BUILD ARG VALUE DESCRIPTION
GO_VERSION 1.22 sets the Go version for the build
```
For more examples on how to write Dockerfile docstrings,
check out [the Dockerfile for Docker docs](https://github.com/docker/docs/blob/main/Dockerfile).
#### Call: check (--check) {#check}
The `check` method evaluates build checks without executing the build. The
`--check` flag is a convenient shorthand for `--call=check`. Use the `check`
method to validate the build configuration before starting the build.
```console
$ docker buildx build -q --check https://github.com/docker/docs.git
WARNING: InvalidBaseImagePlatform
Base image wjdp/htmltest:v0.17.0 was pulled with platform "linux/amd64", expected "linux/arm64" for current build
Dockerfile:43
--------------------
41 | "#content/desktop/previous-versions/*.md"
42 |
43 | >>> FROM wjdp/htmltest:v${HTMLTEST_VERSION} AS test
44 | WORKDIR /test
45 | COPY --from=build /out ./public
--------------------
```
Using `--check` without specifying a target evaluates the entire Dockerfile.
If you want to evaluate a specific target, use the `--target` flag.
#### Call: outline
The `outline` method prints the name of the specified target (or the default
target, if `--target` isn't specified), and the build arguments that the target
consumes, along with their default values, if set.
The following example shows the default target `release` and its build arguments:
```console
$ docker buildx build -q --call=outline https://github.com/docker/docs.git
TARGET: release
DESCRIPTION: is an empty scratch image with only compiled assets
BUILD ARG VALUE DESCRIPTION
GO_VERSION 1.22 sets the Go version for the base stage
HUGO_VERSION 0.127.0
HUGO_ENV sets the hugo.Environment (production, development, preview)
DOCS_URL sets the base URL for the site
PAGEFIND_VERSION 1.1.0
```
This means that the `release` target is configurable using these build arguments:
```console
$ docker buildx build \
--build-arg GO_VERSION=1.22 \
--build-arg HUGO_VERSION=0.127.0 \
--build-arg HUGO_ENV=production \
--build-arg DOCS_URL=https://example.com \
--build-arg PAGEFIND_VERSION=1.1.0 \
--target release https://github.com/docker/docs.git
```
#### Call: targets
The `targets` method lists all the build targets in the Dockerfile. These are
the stages that you can build using the `--target` flag. It also indicates the
default target, which is the target that will be built when you don't specify a
target.
```console
$ docker buildx build -q --call=targets https://github.com/docker/docs.git
TARGET DESCRIPTION
base is the base stage with build dependencies
node installs Node.js dependencies
hugo downloads and extracts the Hugo binary
build-base is the base stage for building the site
dev is for local development with Docker Compose
build creates production builds with Hugo
lint lints markdown files
test validates HTML output and checks for broken links
update-modules downloads and vendors Hugo modules
vendor is an empty stage with only vendored Hugo modules
build-upstream builds an upstream project with a replacement module
validate-upstream validates HTML output for upstream builds
unused-media checks for unused graphics and other media
pagefind installs the Pagefind runtime
index generates a Pagefind index
test-go-redirects checks that the /go/ redirects are valid
release (default) is an empty scratch image with only compiled assets
```
### Export build cache to an external cache destination (--cache-to) {#cache-to}
```text
@ -787,6 +1004,27 @@ examples: |-
More info about cache exporters and available attributes: https://github.com/moby/buildkit#export-cache
### Use a custom parent cgroup (--cgroup-parent) {#cgroup-parent}
When you run `docker buildx build` with the `--cgroup-parent` option,
the daemon runs the containers used in the build with the
[corresponding `docker run` flag](/reference/cli/docker/container/run/#cgroup-parent).
### Specify a Dockerfile (-f, --file) {#file}
```console
$ docker buildx build -f <filepath> .
```
Specifies the filepath of the Dockerfile to use.
If unspecified, a file named `Dockerfile` at the root of the build context is used by default.
To read a Dockerfile from stdin, you can use `-` as the argument for `--file`.
```console
$ cat Dockerfile | docker buildx build -f - .
```
### Load the single-platform build result to `docker images` (--load) {#load}
Shorthand for [`--output=type=docker`](#docker). Will automatically load the
@ -807,6 +1045,7 @@ examples: |-
{
"buildx.build.provenance": {},
"buildx.build.ref": "mybuilder/mybuilder0/0fjb6ubs52xx3vygf6fgdl611",
"buildx.build.warnings": {},
"containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
"containerimage.descriptor": {
"annotations": {
@ -826,9 +1065,26 @@ examples: |-
> Build record [provenance](/build/attestations/slsa-provenance/#provenance-attestation-example)
> (`buildx.build.provenance`) includes minimal provenance by default. Set the
> `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior:
> * `min` sets minimal provenance (default).
> * `max` sets full provenance.
> * `disabled`, `false` or `0` does not set any provenance.
>
> - `min` sets minimal provenance (default).
> - `max` sets full provenance.
> - `disabled`, `false` or `0` doesn't set any provenance.
### Set the networking mode for the RUN instructions during build (--network) {#network}
Available options for the networking mode are:
- `default` (default): Run in the default network.
- `none`: Run with no network access.
- `host`: Run in the hosts network environment.
Find more details in the [Dockerfile reference](/reference/dockerfile/#run---network).
> **Note**
>
> Build warnings (`buildx.build.warnings`) are not included by default. Set the
> `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
> include them.
### Ignore build cache for specific stages (--no-cache-filter) {#no-cache-filter}
@ -891,17 +1147,19 @@ examples: |-
-o, --output=[PATH,-,type=TYPE[,KEY=VALUE]
```
Sets the export action for the build result. In `docker build` all builds finish
by creating a container image and exporting it to `docker images`. `buildx` makes
this step configurable allowing results to be exported directly to the client,
OCI image tarballs, registry etc.
Sets the export action for the build result. The default output, when using the
`docker` [build driver](/build/drivers/), is a container
image exported to the local image store. The `--output` flag makes this step
configurable allows export of results directly to the client's filesystem, an
OCI image tarball, a registry, and more.
Buildx with `docker` driver currently only supports local, tarball exporter and
image exporter. `docker-container` driver supports all the exporters.
Buildx with `docker` driver only supports the local, tarball, and image
[exporters](/build/exporters/). The `docker-container`
driver supports all exporters.
If just the path is specified as a value, `buildx` will use the local exporter
with this path as the destination. If the value is "-", `buildx` will use `tar`
exporter and write to `stdout`.
If you only specify a filepath as the argument to `--output`, Buildx uses the
local exporter. If the value is `-`, Buildx uses the `tar` exporter and writes
the output to stdout.
```console
$ docker buildx build -o . .
@ -912,12 +1170,17 @@ examples: |-
$ docker buildx build -t tonistiigi/foo -o type=registry
```
> **Note **
>
> Since BuildKit v0.13.0 multiple outputs can be specified by repeating the flag.
You can export multiple outputs by repeating the flag.
Supported exported types are:
- [`local`](#local)
- [`tar`](#tar)
- [`oci`](#oci)
- [`docker`](#docker)
- [`image`](#image)
- [`registry`](#registry)
#### `local`
The `local` export type writes all result files to a directory on the client. The
@ -928,6 +1191,9 @@ examples: |-
- `dest` - destination directory where files will be written
For more information, see
[Local and tar exporters](/build/exporters/local-tar/).
#### `tar`
The `tar` export type writes all result files as a single tarball on the client.
@ -937,6 +1203,9 @@ examples: |-
- `dest` - destination path where tarball will be written. “-” writes to stdout.
For more information, see
[Local and tar exporters](/build/exporters/local-tar/).
#### `oci`
The `oci` export type writes the result image or manifest list as an [OCI image
@ -947,6 +1216,9 @@ examples: |-
- `dest` - destination path where tarball will be written. “-” writes to stdout.
For more information, see
[OCI and Docker exporters](/build/exporters/oci-docker/).
#### `docker`
The `docker` export type writes the single-platform result image as a [Docker image
@ -963,6 +1235,9 @@ examples: |-
the tar will be loaded automatically to the local image store.
- `context` - name for the Docker context where to import the result
For more information, see
[OCI and Docker exporters](/build/exporters/oci-docker/).
#### `image`
The `image` exporter writes the build result as an image or a manifest list. When
@ -974,10 +1249,16 @@ examples: |-
- `name` - name (references) for the new image.
- `push` - Boolean to automatically push the image.
For more information, see
[Image and registry exporters](/build/exporters/image-registry/).
#### `registry`
The `registry` exporter is a shortcut for `type=image,push=true`.
For more information, see
[Image and registry exporters](/build/exporters/image-registry/).
### Set the target platforms for the build (--platform) {#platform}
```text
@ -1004,13 +1285,12 @@ examples: |-
commands for your system architecture.
If your kernel supports [`binfmt_misc`](https://en.wikipedia.org/wiki/Binfmt_misc)
launchers for secondary architectures, buildx will pick them up automatically.
Docker desktop releases come with `binfmt_misc` automatically configured for `arm64`
Docker Desktop releases come with `binfmt_misc` automatically configured for `arm64`
and `arm` architectures. You can see what runtime platforms your current builder
instance supports by running `docker buildx inspect --bootstrap`.
Inside a `Dockerfile`, you can access the current platform value through
`TARGETPLATFORM` build argument. Refer to the [`docker build`
documentation](/reference/dockerfile/#automatic-platform-args-in-the-global-scope)
`TARGETPLATFORM` build argument. Refer to the [Dockerfile reference](/reference/dockerfile/#automatic-platform-args-in-the-global-scope)
for the full description of automatic platform argument variants .
You can find the formatting definition for the platform specifier in the
@ -1203,6 +1483,46 @@ examples: |-
$ docker buildx build --ssh default=$SSH_AUTH_SOCK .
```
### Tag an image (-t, --tag) {#tag}
```console
$ docker buildx build -t docker/apache:2.0 .
```
This examples builds in the same way as the previous example, but it then tags the resulting
image. The repository name will be `docker/apache` and the tag `2.0`.
[Read more about valid tags](/reference/cli/docker/image/tag/).
You can apply multiple tags to an image. For example, you can apply the `latest`
tag to a newly built image and add another tag that references a specific
version.
For example, to tag an image both as `docker/fedora-jboss:latest` and
`docker/fedora-jboss:v2.1`, use the following:
```console
$ docker buildx build -t docker/fedora-jboss:latest -t docker/fedora-jboss:v2.1 .
```
### Specifying target build stage (--target) {#target}
When building a Dockerfile with multiple build stages, use the `--target`
option to specify an intermediate build stage by name as a final stage for the
resulting image. The builder skips commands after the target stage.
```dockerfile
FROM debian AS build-env
# ...
FROM alpine AS production-env
# ...
```
```console
$ docker buildx build -t mybuildimage --target build-env .
```
### Set ulimits (--ulimit) {#ulimit}
`--ulimit` overrides the default ulimits of build's containers when using `RUN`

View File

@ -1,5 +1,5 @@
command: docker buildx debug build
aliases: docker buildx debug build, docker buildx debug b
aliases: docker build, docker builder build, docker image build, docker buildx b
short: Start a build
long: Start a build
usage: docker buildx debug build [OPTIONS] PATH | URL | -
@ -10,7 +10,6 @@ options:
value_type: stringSlice
default_value: '[]'
description: 'Add a custom host-to-IP mapping (format: `host:ip`)'
details_url: /reference/cli/docker/image/build/#add-host
deprecated: false
hidden: false
experimental: false
@ -103,7 +102,6 @@ options:
- option: cgroup-parent
value_type: string
description: Set the parent cgroup for the `RUN` instructions during build
details_url: /reference/cli/docker/image/build/#cgroup-parent
deprecated: false
hidden: false
experimental: false
@ -192,7 +190,6 @@ options:
shorthand: f
value_type: string
description: 'Name of the Dockerfile (default: `PATH/Dockerfile`)'
details_url: /reference/cli/docker/image/build/#file
deprecated: false
hidden: false
experimental: false
@ -482,7 +479,6 @@ options:
value_type: stringArray
default_value: '[]'
description: 'Name and optionally a tag (format: `name:tag`)'
details_url: /reference/cli/docker/image/build/#tag
deprecated: false
hidden: false
experimental: false
@ -492,7 +488,6 @@ options:
- option: target
value_type: string
description: Set the target build stage to build
details_url: /reference/cli/docker/image/build/#target
deprecated: false
hidden: false
experimental: false

10
go.mod
View File

@ -1,20 +1,20 @@
module github.com/docker/docs
go 1.21
go 1.21.0
toolchain go1.21.1
toolchain go1.22.5
require (
github.com/docker/buildx v0.15.1 // indirect
github.com/docker/buildx v0.16.0 // indirect
github.com/docker/cli v27.0.3+incompatible // indirect
github.com/docker/compose/v2 v2.28.1 // indirect
github.com/docker/scout-cli v1.10.0 // indirect
github.com/moby/buildkit v0.14.1 // indirect
github.com/moby/buildkit v0.15.0 // indirect
github.com/moby/moby v27.0.3+incompatible // indirect
)
replace (
github.com/docker/buildx => github.com/docker/buildx v0.15.1
github.com/docker/buildx => github.com/docker/buildx v0.16.0
github.com/docker/cli => github.com/docker/cli v27.0.3+incompatible
github.com/docker/compose/v2 => github.com/docker/compose/v2 v2.28.1
github.com/docker/scout-cli => github.com/docker/scout-cli v1.10.0

2
go.sum
View File

@ -74,6 +74,8 @@ github.com/docker/buildx v0.15.0 h1:PVq4IMnTvw1Sx0RKDWbfi2eTGawFd9CMBYnz9xat93Y=
github.com/docker/buildx v0.15.0/go.mod h1:AdkB1RIcU4rfZ6mpw2PA2pOi1ppI9yvFXkVEpq5EmS4=
github.com/docker/buildx v0.15.1 h1:1cO6JIc0rOoC8tlxfXoh1HH1uxaNvYH1q7J7kv5enhw=
github.com/docker/buildx v0.15.1/go.mod h1:16DQgJqoggmadc1UhLaUTPqKtR+PlByN/kyXFdkhFCo=
github.com/docker/buildx v0.16.0 h1:LurEflyb6BBoLtDwJY1dw9dLHKzEgGvCjAz67QI0xO0=
github.com/docker/buildx v0.16.0/go.mod h1:4xduW7BOJ2B11AyORKZFDKjF6Vcb4EgTYnV2nunxv9I=
github.com/docker/cli v24.0.2+incompatible h1:QdqR7znue1mtkXIJ+ruQMGQhpw2JzMJLRXp6zpzF6tM=
github.com/docker/cli v24.0.2+incompatible/go.mod h1:JLrzqnKDaYBop7H2jaqPtU4hHvMKP+vjCwu2uszcLI8=
github.com/docker/cli v24.0.4+incompatible h1:Y3bYF9ekNTm2VFz5U/0BlMdJy73D+Y1iAAZ8l63Ydzw=