github.com/pdmccormick/importable-docker-buildx@v0.0.0-20240426161518-e47091289030/docs/reference/buildx_build.md (about) 1 # buildx build 2 3 ```text 4 docker buildx build [OPTIONS] PATH | URL | - 5 ``` 6 7 <!---MARKER_GEN_START--> 8 Start a build 9 10 ### Aliases 11 12 `docker buildx build`, `docker buildx b` 13 14 ### Options 15 16 | Name | Type | Default | Description | 17 |:---------------------------------------------------------------------------------------------------------------------------------------------------|:--------------|:----------|:----------------------------------------------------------------------------------------------------| 18 | [`--add-host`](https://docs.docker.com/reference/cli/docker/image/build/#add-host) | `stringSlice` | | Add a custom host-to-IP mapping (format: `host:ip`) | 19 | [`--allow`](#allow) | `stringSlice` | | Allow extra privileged entitlement (e.g., `network.host`, `security.insecure`) | 20 | [`--annotation`](#annotation) | `stringArray` | | Add annotation to the image | 21 | [`--attest`](#attest) | `stringArray` | | Attestation parameters (format: `type=sbom,generator=image`) | 22 | [`--build-arg`](#build-arg) | `stringArray` | | Set build-time variables | 23 | [`--build-context`](#build-context) | `stringArray` | | Additional build contexts (e.g., name=path) | 24 | [`--builder`](#builder) | `string` | | Override the configured builder instance | 25 | [`--cache-from`](#cache-from) | `stringArray` | | External cache sources (e.g., `user/app:cache`, `type=local,src=path/to/dir`) | 26 | [`--cache-to`](#cache-to) | `stringArray` | | Cache export destinations (e.g., `user/app:cache`, `type=local,dest=path/to/dir`) | 27 | [`--cgroup-parent`](https://docs.docker.com/reference/cli/docker/image/build/#cgroup-parent) | `string` | | Set the parent cgroup for the `RUN` instructions during build | 28 | `--detach` | | | Detach buildx server (supported only on linux) (EXPERIMENTAL) | 29 | [`-f`](https://docs.docker.com/reference/cli/docker/image/build/#file), [`--file`](https://docs.docker.com/reference/cli/docker/image/build/#file) | `string` | | Name of the Dockerfile (default: `PATH/Dockerfile`) | 30 | `--iidfile` | `string` | | Write the image ID to a file | 31 | `--label` | `stringArray` | | Set metadata for an image | 32 | [`--load`](#load) | | | Shorthand for `--output=type=docker` | 33 | [`--metadata-file`](#metadata-file) | `string` | | Write build result metadata to a file | 34 | `--network` | `string` | `default` | Set the networking mode for the `RUN` instructions during build | 35 | `--no-cache` | | | Do not use cache when building the image | 36 | [`--no-cache-filter`](#no-cache-filter) | `stringArray` | | Do not cache specified stages | 37 | [`-o`](#output), [`--output`](#output) | `stringArray` | | Output destination (format: `type=local,dest=path`) | 38 | [`--platform`](#platform) | `stringArray` | | Set target platform for build | 39 | `--print` | `string` | | Print result of information request (e.g., outline, targets) (EXPERIMENTAL) | 40 | [`--progress`](#progress) | `string` | `auto` | Set type of progress output (`auto`, `plain`, `tty`). Use plain to show container output | 41 | [`--provenance`](#provenance) | `string` | | Shorthand for `--attest=type=provenance` | 42 | `--pull` | | | Always attempt to pull all referenced images | 43 | [`--push`](#push) | | | Shorthand for `--output=type=registry` | 44 | `-q`, `--quiet` | | | Suppress the build output and print image ID on success | 45 | `--root` | `string` | | Specify root directory of server to connect (EXPERIMENTAL) | 46 | [`--sbom`](#sbom) | `string` | | Shorthand for `--attest=type=sbom` | 47 | [`--secret`](#secret) | `stringArray` | | Secret to expose to the build (format: `id=mysecret[,src=/local/secret]`) | 48 | `--server-config` | `string` | | Specify buildx server config file (used only when launching new server) (EXPERIMENTAL) | 49 | [`--shm-size`](#shm-size) | `bytes` | `0` | Shared memory size for build containers | 50 | [`--ssh`](#ssh) | `stringArray` | | SSH agent socket or keys to expose to the build (format: `default\|<id>[=<socket>\|<key>[,<key>]]`) | 51 | [`-t`](https://docs.docker.com/reference/cli/docker/image/build/#tag), [`--tag`](https://docs.docker.com/reference/cli/docker/image/build/#tag) | `stringArray` | | Name and optionally a tag (format: `name:tag`) | 52 | [`--target`](https://docs.docker.com/reference/cli/docker/image/build/#target) | `string` | | Set the target build stage to build | 53 | [`--ulimit`](#ulimit) | `ulimit` | | Ulimit options | 54 55 56 <!---MARKER_GEN_END--> 57 58 Flags marked with `[experimental]` need to be explicitly enabled by setting the 59 `BUILDX_EXPERIMENTAL=1` environment variable. 60 61 ## Description 62 63 The `buildx build` command starts a build using BuildKit. This command is similar 64 to the UI of `docker build` command and takes the same flags and arguments. 65 66 For documentation on most of these flags, refer to the [`docker build` 67 documentation](https://docs.docker.com/reference/cli/docker/image/build/). 68 This page describes a subset of the new flags. 69 70 ## Examples 71 72 ### <a name="annotation"></a> Create annotations (--annotation) 73 74 ```text 75 --annotation="key=value" 76 --annotation="[type:]key=value" 77 ``` 78 79 Add OCI annotations to the image index, manifest, or descriptor. 80 The following example adds the `foo=bar` annotation to the image manifests: 81 82 ```console 83 $ docker buildx build -t TAG --annotation "foo=bar" --push . 84 ``` 85 86 You can optionally add a type prefix to specify the level of the annotation. By 87 default, the image manifest is annotated. The following example adds the 88 `foo=bar` annotation the image index instead of the manifests: 89 90 ```console 91 $ docker buildx build -t TAG --annotation "index:foo=bar" --push . 92 ``` 93 94 You can specify multiple types, separated by a comma (,) to add the annotation 95 to multiple image components. The following example adds the `foo=bar` 96 annotation to image index, descriptors, manifests: 97 98 ```console 99 $ docker buildx build -t TAG --annotation "index,manifest,manifest-descriptor:foo=bar" --push . 100 ``` 101 102 You can also specify a platform qualifier in square brackets (`[os/arch]`) in 103 the type prefix, to apply the annotation to a subset of manifests with the 104 matching platform. The following example adds the `foo=bar` annotation only to 105 the manifest with the `linux/amd64` platform: 106 107 ```console 108 $ docker buildx build -t TAG --annotation "manifest[linux/amd64]:foo=bar" --push . 109 ``` 110 111 Wildcards are not supported in the platform qualifier; you can't specify a type 112 prefix like `manifest[linux/*]` to add annotations only to manifests which has 113 `linux` as the OS platform. 114 115 For more information about annotations, see 116 [Annotations](https://docs.docker.com/build/building/annotations/). 117 118 ### <a name="attest"></a> Create attestations (--attest) 119 120 ```text 121 --attest=type=sbom,... 122 --attest=type=provenance,... 123 ``` 124 125 Create [image attestations](https://docs.docker.com/build/attestations/). 126 BuildKit currently supports: 127 128 - `sbom` - Software Bill of Materials. 129 130 Use `--attest=type=sbom` to generate an SBOM for an image at build-time. 131 Alternatively, you can use the [`--sbom` shorthand](#sbom). 132 133 For more information, see [here](https://docs.docker.com/build/attestations/sbom/). 134 135 - `provenance` - SLSA Provenance 136 137 Use `--attest=type=provenance` to generate provenance for an image at 138 build-time. Alternatively, you can use the [`--provenance` shorthand](#provenance). 139 140 By default, a minimal provenance attestation will be created for the build 141 result, which will only be attached for images pushed to registries. 142 143 For more information, see [here](https://docs.docker.com/build/attestations/slsa-provenance/). 144 145 ### <a name="allow"></a> Allow extra privileged entitlement (--allow) 146 147 ```text 148 --allow=ENTITLEMENT 149 ``` 150 151 Allow extra privileged entitlement. List of entitlements: 152 153 - `network.host` - Allows executions with host networking. 154 - `security.insecure` - Allows executions without sandbox. See 155 [related Dockerfile extensions](https://docs.docker.com/reference/dockerfile/#run---security). 156 157 For entitlements to be enabled, the BuildKit daemon also needs to allow them 158 with `--allow-insecure-entitlement` (see [`create --buildkitd-flags`](buildx_create.md#buildkitd-flags)). 159 160 ```console 161 $ docker buildx create --use --name insecure-builder --buildkitd-flags '--allow-insecure-entitlement security.insecure' 162 $ docker buildx build --allow security.insecure . 163 ``` 164 165 ### <a name="build-arg"></a> Set build-time variables (--build-arg) 166 167 Same as [`docker build` command](https://docs.docker.com/reference/cli/docker/image/build/#build-arg). 168 169 There are also useful built-in build arguments, such as: 170 171 * `BUILDKIT_CONTEXT_KEEP_GIT_DIR=<bool>`: trigger git context to keep the `.git` directory 172 * `BUILDKIT_INLINE_CACHE=<bool>`: inline cache metadata to image config or not 173 * `BUILDKIT_MULTI_PLATFORM=<bool>`: opt into deterministic output regardless of multi-platform output or not 174 175 ```console 176 $ docker buildx build --build-arg BUILDKIT_MULTI_PLATFORM=1 . 177 ``` 178 179 Learn more about the built-in build arguments in the [Dockerfile reference docs](https://docs.docker.com/reference/dockerfile/#buildkit-built-in-build-args). 180 181 ### <a name="build-context"></a> Additional build contexts (--build-context) 182 183 ```text 184 --build-context=name=VALUE 185 ``` 186 187 Define additional build context with specified contents. In Dockerfile the context can be accessed when `FROM name` or `--from=name` is used. 188 When Dockerfile defines a stage with the same name it is overwritten. 189 190 The value can be a local source directory, [local OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md), container image (with docker-image:// prefix), Git or HTTP URL. 191 192 Replace `alpine:latest` with a pinned one: 193 194 ```console 195 $ docker buildx build --build-context alpine=docker-image://alpine@sha256:0123456789 . 196 ``` 197 198 Expose a secondary local source directory: 199 200 ```console 201 $ docker buildx build --build-context project=path/to/project/source . 202 # docker buildx build --build-context project=https://github.com/myuser/project.git . 203 ``` 204 205 ```dockerfile 206 # syntax=docker/dockerfile:1 207 FROM alpine 208 COPY --from=project myfile / 209 ``` 210 211 #### <a name="source-oci-layout"></a> Use an OCI layout directory as build context 212 213 Source an image from a local [OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md), 214 either by tag, or by digest: 215 216 ```console 217 $ docker buildx build --build-context foo=oci-layout:///path/to/local/layout:<tag> 218 $ docker buildx build --build-context foo=oci-layout:///path/to/local/layout@sha256:<digest> 219 ``` 220 221 ```dockerfile 222 # syntax=docker/dockerfile:1 223 FROM alpine 224 RUN apk add git 225 COPY --from=foo myfile / 226 227 FROM foo 228 ``` 229 230 The OCI layout directory must be compliant with the [OCI layout specification](https://github.com/opencontainers/image-spec/blob/main/image-layout.md). 231 You can reference an image in the layout using either tags, or the exact digest. 232 233 ### <a name="builder"></a> Override the configured builder instance (--builder) 234 235 Same as [`buildx --builder`](buildx.md#builder). 236 237 ### <a name="cache-from"></a> Use an external cache source for a build (--cache-from) 238 239 ```text 240 --cache-from=[NAME|type=TYPE[,KEY=VALUE]] 241 ``` 242 243 Use an external cache source for a build. Supported types are `registry`, 244 `local`, `gha` and `s3`. 245 246 - [`registry` source](https://github.com/moby/buildkit#registry-push-image-and-cache-separately) 247 can import cache from a cache manifest or (special) image configuration on the 248 registry. 249 - [`local` source](https://github.com/moby/buildkit#local-directory-1) can 250 import cache from local files previously exported with `--cache-to`. 251 - [`gha` source](https://github.com/moby/buildkit#github-actions-cache-experimental) 252 can import cache from a previously exported cache with `--cache-to` in your 253 GitHub repository 254 - [`s3` source](https://github.com/moby/buildkit#s3-cache-experimental) 255 can import cache from a previously exported cache with `--cache-to` in your 256 S3 bucket 257 258 If no type is specified, `registry` exporter is used with a specified reference. 259 260 `docker` driver currently only supports importing build cache from the registry. 261 262 ```console 263 $ docker buildx build --cache-from=user/app:cache . 264 $ docker buildx build --cache-from=user/app . 265 $ docker buildx build --cache-from=type=registry,ref=user/app . 266 $ docker buildx build --cache-from=type=local,src=path/to/cache . 267 $ docker buildx build --cache-from=type=gha . 268 $ docker buildx build --cache-from=type=s3,region=eu-west-1,bucket=mybucket . 269 ``` 270 271 More info about cache exporters and available attributes: https://github.com/moby/buildkit#export-cache 272 273 ### <a name="cache-to"></a> Export build cache to an external cache destination (--cache-to) 274 275 ```text 276 --cache-to=[NAME|type=TYPE[,KEY=VALUE]] 277 ``` 278 279 Export build cache to an external cache destination. Supported types are 280 `registry`, `local`, `inline`, `gha` and `s3`. 281 282 - [`registry` type](https://github.com/moby/buildkit#registry-push-image-and-cache-separately) exports build cache to a cache manifest in the registry. 283 - [`local` type](https://github.com/moby/buildkit#local-directory-1) exports 284 cache to a local directory on the client. 285 - [`inline` type](https://github.com/moby/buildkit#inline-push-image-and-cache-together) 286 writes the cache metadata into the image configuration. 287 - [`gha` type](https://github.com/moby/buildkit#github-actions-cache-experimental) 288 exports cache through the [GitHub Actions Cache service API](https://github.com/tonistiigi/go-actions-cache/blob/master/api.md#authentication). 289 - [`s3` type](https://github.com/moby/buildkit#s3-cache-experimental) exports 290 cache to a S3 bucket. 291 292 The `docker` driver only supports cache exports using the `inline` and `local` 293 cache backends. 294 295 Attribute key: 296 297 - `mode` - Specifies how many layers are exported with the cache. `min` on only 298 exports layers already in the final build stage, `max` exports layers for 299 all stages. Metadata is always exported for the whole build. 300 301 ```console 302 $ docker buildx build --cache-to=user/app:cache . 303 $ docker buildx build --cache-to=type=inline . 304 $ docker buildx build --cache-to=type=registry,ref=user/app . 305 $ docker buildx build --cache-to=type=local,dest=path/to/cache . 306 $ docker buildx build --cache-to=type=gha . 307 $ docker buildx build --cache-to=type=s3,region=eu-west-1,bucket=mybucket . 308 ``` 309 310 More info about cache exporters and available attributes: https://github.com/moby/buildkit#export-cache 311 312 ### <a name="load"></a> Load the single-platform build result to `docker images` (--load) 313 314 Shorthand for [`--output=type=docker`](#docker). Will automatically load the 315 single-platform build result to `docker images`. 316 317 ### <a name="metadata-file"></a> Write build result metadata to a file (--metadata-file) 318 319 To output build metadata such as the image digest, pass the `--metadata-file` flag. 320 The metadata will be written as a JSON object to the specified file. The 321 directory of the specified file must already exist and be writable. 322 323 ```console 324 $ docker buildx build --load --metadata-file metadata.json . 325 $ cat metadata.json 326 ``` 327 328 ```json 329 { 330 "buildx.build.provenance": {}, 331 "buildx.build.ref": "mybuilder/mybuilder0/0fjb6ubs52xx3vygf6fgdl611", 332 "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", 333 "containerimage.descriptor": { 334 "annotations": { 335 "config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66", 336 "org.opencontainers.image.created": "2022-02-08T21:28:03Z" 337 }, 338 "digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3", 339 "mediaType": "application/vnd.oci.image.manifest.v1+json", 340 "size": 506 341 }, 342 "containerimage.digest": "sha256:19ffeab6f8bc9293ac2c3fdf94ebe28396254c993aea0b5a542cfb02e0883fa3" 343 } 344 ``` 345 346 > **Note** 347 > 348 > Build record [provenance](https://docs.docker.com/build/attestations/slsa-provenance/#provenance-attestation-example) 349 > (`buildx.build.provenance`) includes minimal provenance by default. Set the 350 > `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior: 351 > * `min` sets minimal provenance (default). 352 > * `max` sets full provenance. 353 > * `disabled`, `false` or `0` does not set any provenance. 354 355 ### <a name="no-cache-filter"></a> Ignore build cache for specific stages (--no-cache-filter) 356 357 The `--no-cache-filter` lets you specify one or more stages of a multi-stage 358 Dockerfile for which build cache should be ignored. To specify multiple stages, 359 use a comma-separated syntax: 360 361 ```console 362 $ docker buildx build --no-cache-filter stage1,stage2,stage3 . 363 ``` 364 365 For example, the following Dockerfile contains four stages: 366 367 - `base` 368 - `install` 369 - `test` 370 - `release` 371 372 ```dockerfile 373 # syntax=docker/dockerfile:1 374 375 FROM oven/bun:1 as base 376 WORKDIR /app 377 378 FROM base AS install 379 WORKDIR /temp/dev 380 RUN --mount=type=bind,source=package.json,target=package.json \ 381 --mount=type=bind,source=bun.lockb,target=bun.lockb \ 382 bun install --frozen-lockfile 383 384 FROM base AS test 385 COPY --from=install /temp/dev/node_modules node_modules 386 COPY . . 387 RUN bun test 388 389 FROM base AS release 390 ENV NODE_ENV=production 391 COPY --from=install /temp/dev/node_modules node_modules 392 COPY . . 393 ENTRYPOINT ["bun", "run", "index.js"] 394 ``` 395 396 To ignore the cache for the `install` stage: 397 398 ```console 399 $ docker buildx build --no-cache-filter install . 400 ``` 401 402 To ignore the cache the `install` and `release` stages: 403 404 ```console 405 $ docker buildx build --no-cache-filter install,release . 406 ``` 407 408 The arguments for the `--no-cache-filter` flag must be names of stages. 409 410 ### <a name="output"></a> Set the export action for the build result (-o, --output) 411 412 ```text 413 -o, --output=[PATH,-,type=TYPE[,KEY=VALUE] 414 ``` 415 416 Sets the export action for the build result. In `docker build` all builds finish 417 by creating a container image and exporting it to `docker images`. `buildx` makes 418 this step configurable allowing results to be exported directly to the client, 419 OCI image tarballs, registry etc. 420 421 Buildx with `docker` driver currently only supports local, tarball exporter and 422 image exporter. `docker-container` driver supports all the exporters. 423 424 If just the path is specified as a value, `buildx` will use the local exporter 425 with this path as the destination. If the value is "-", `buildx` will use `tar` 426 exporter and write to `stdout`. 427 428 ```console 429 $ docker buildx build -o . . 430 $ docker buildx build -o outdir . 431 $ docker buildx build -o - . > out.tar 432 $ docker buildx build -o type=docker . 433 $ docker buildx build -o type=docker,dest=- . > myimage.tar 434 $ docker buildx build -t tonistiigi/foo -o type=registry 435 ``` 436 437 > **Note ** 438 > 439 > Since BuildKit v0.13.0 multiple outputs can be specified by repeating the flag. 440 441 Supported exported types are: 442 443 #### `local` 444 445 The `local` export type writes all result files to a directory on the client. The 446 new files will be owned by the current user. On multi-platform builds, all results 447 will be put in subdirectories by their platform. 448 449 Attribute key: 450 451 - `dest` - destination directory where files will be written 452 453 #### `tar` 454 455 The `tar` export type writes all result files as a single tarball on the client. 456 On multi-platform builds all results will be put in subdirectories by their platform. 457 458 Attribute key: 459 460 - `dest` - destination path where tarball will be written. “-” writes to stdout. 461 462 #### `oci` 463 464 The `oci` export type writes the result image or manifest list as an [OCI image 465 layout](https://github.com/opencontainers/image-spec/blob/v1.0.1/image-layout.md) 466 tarball on the client. 467 468 Attribute key: 469 470 - `dest` - destination path where tarball will be written. “-” writes to stdout. 471 472 #### `docker` 473 474 The `docker` export type writes the single-platform result image as a [Docker image 475 specification](https://github.com/docker/docker/blob/v20.10.2/image/spec/v1.2.md) 476 tarball on the client. Tarballs created by this exporter are also OCI compatible. 477 478 The default image store in Docker Engine doesn't support loading multi-platform 479 images. You can enable the containerd image store, or push multi-platform images 480 is to directly push to a registry, see [`registry`](#registry). 481 482 Attribute keys: 483 484 - `dest` - destination path where tarball will be written. If not specified, 485 the tar will be loaded automatically to the local image store. 486 - `context` - name for the Docker context where to import the result 487 488 #### `image` 489 490 The `image` exporter writes the build result as an image or a manifest list. When 491 using `docker` driver the image will appear in `docker images`. Optionally, image 492 can be automatically pushed to a registry by specifying attributes. 493 494 Attribute keys: 495 496 - `name` - name (references) for the new image. 497 - `push` - Boolean to automatically push the image. 498 499 #### `registry` 500 501 The `registry` exporter is a shortcut for `type=image,push=true`. 502 503 ### <a name="platform"></a> Set the target platforms for the build (--platform) 504 505 ```text 506 --platform=value[,value] 507 ``` 508 509 Set the target platform for the build. All `FROM` commands inside the Dockerfile 510 without their own `--platform` flag will pull base images for this platform and 511 this value will also be the platform of the resulting image. 512 513 The default value is the platform of the BuildKit daemon where the build runs. 514 The value takes the form of `os/arch` or `os/arch/variant`. For example, 515 `linux/amd64` or `linux/arm/v7`. Additionally, the `--platform` flag also supports 516 a special `local` value, which tells BuildKit to use the platform of the BuildKit 517 client that invokes the build. 518 519 When using `docker-container` driver with `buildx`, this flag can accept multiple 520 values as an input separated by a comma. With multiple values the result will be 521 built for all of the specified platforms and joined together into a single manifest 522 list. 523 524 If the `Dockerfile` needs to invoke the `RUN` command, the builder needs runtime 525 support for the specified platform. In a clean setup, you can only execute `RUN` 526 commands for your system architecture. 527 If your kernel supports [`binfmt_misc`](https://en.wikipedia.org/wiki/Binfmt_misc) 528 launchers for secondary architectures, buildx will pick them up automatically. 529 Docker desktop releases come with `binfmt_misc` automatically configured for `arm64` 530 and `arm` architectures. You can see what runtime platforms your current builder 531 instance supports by running `docker buildx inspect --bootstrap`. 532 533 Inside a `Dockerfile`, you can access the current platform value through 534 `TARGETPLATFORM` build argument. Refer to the [`docker build` 535 documentation](https://docs.docker.com/reference/dockerfile/#automatic-platform-args-in-the-global-scope) 536 for the full description of automatic platform argument variants . 537 538 You can find the formatting definition for the platform specifier in the 539 [containerd source code](https://github.com/containerd/containerd/blob/v1.4.3/platforms/platforms.go#L63). 540 541 ```console 542 $ docker buildx build --platform=linux/arm64 . 543 $ docker buildx build --platform=linux/amd64,linux/arm64,linux/arm/v7 . 544 $ docker buildx build --platform=darwin . 545 ``` 546 547 ### <a name="progress"></a> Set type of progress output (--progress) 548 549 ```text 550 --progress=VALUE 551 ``` 552 553 Set type of progress output (`auto`, `plain`, `tty`). Use plain to show container 554 output (default "auto"). 555 556 > **Note** 557 > 558 > You can also use the `BUILDKIT_PROGRESS` environment variable to set its value. 559 560 The following example uses `plain` output during the build: 561 562 ```console 563 $ docker buildx build --load --progress=plain . 564 565 #1 [internal] load build definition from Dockerfile 566 #1 transferring dockerfile: 227B 0.0s done 567 #1 DONE 0.1s 568 569 #2 [internal] load .dockerignore 570 #2 transferring context: 129B 0.0s done 571 #2 DONE 0.0s 572 ... 573 ``` 574 575 > **Note** 576 > 577 > Check also the [`BUILDKIT_COLORS`](https://docs.docker.com/build/building/variables/#buildkit_colors) 578 > environment variable for modifying the colors of the terminal output. 579 580 ### <a name="provenance"></a> Create provenance attestations (--provenance) 581 582 Shorthand for [`--attest=type=provenance`](#attest), used to configure 583 provenance attestations for the build result. For example, 584 `--provenance=mode=max` can be used as an abbreviation for 585 `--attest=type=provenance,mode=max`. 586 587 Additionally, `--provenance` can be used with Boolean values to enable or disable 588 provenance attestations. For example, `--provenance=false` disables all provenance attestations, 589 while `--provenance=true` enables all provenance attestations. 590 591 By default, a minimal provenance attestation will be created for the build 592 result. Note that the default image store in Docker Engine doesn't support 593 attestations. Provenance attestations only persist for images pushed directly 594 to a registry if you use the default image store. Alternatively, you can switch 595 to using the containerd image store. 596 597 For more information about provenance attestations, see 598 [here](https://docs.docker.com/build/attestations/slsa-provenance/). 599 600 ### <a name="push"></a> Push the build result to a registry (--push) 601 602 Shorthand for [`--output=type=registry`](#registry). Will automatically push the 603 build result to registry. 604 605 ### <a name="sbom"></a> Create SBOM attestations (--sbom) 606 607 Shorthand for [`--attest=type=sbom`](#attest), used to configure SBOM 608 attestations for the build result. For example, 609 `--sbom=generator=<user>/<generator-image>` can be used as an abbreviation for 610 `--attest=type=sbom,generator=<user>/<generator-image>`. 611 612 Additionally, `--sbom` can be used with Boolean values to enable or disable 613 SBOM attestations. For example, `--sbom=false` disables all SBOM attestations. 614 615 Note that the default image store in Docker Engine doesn't support 616 attestations. Provenance attestations only persist for images pushed directly 617 to a registry if you use the default image store. Alternatively, you can switch 618 to using the containerd image store. 619 620 For more information, see [here](https://docs.docker.com/build/attestations/sbom/). 621 622 ### <a name="secret"></a> Secret to expose to the build (--secret) 623 624 ```text 625 --secret=[type=TYPE[,KEY=VALUE] 626 ``` 627 628 Exposes secrets (authentication credentials, tokens) to the build. 629 A secret can be mounted into the build using a `RUN --mount=type=secret` mount in the 630 [Dockerfile](https://docs.docker.com/reference/dockerfile/#run---mounttypesecret). 631 For more information about how to use build secrets, see 632 [Build secrets](https://docs.docker.com/build/building/secrets/). 633 634 Supported types are: 635 636 - [`file`](#file) 637 - [`env`](#env) 638 639 Buildx attempts to detect the `type` automatically if unset. 640 641 #### `file` 642 643 Attribute keys: 644 645 - `id` - ID of the secret. Defaults to base name of the `src` path. 646 - `src`, `source` - Secret filename. `id` used if unset. 647 648 ```dockerfile 649 # syntax=docker/dockerfile:1 650 FROM python:3 651 RUN pip install awscli 652 RUN --mount=type=secret,id=aws,target=/root/.aws/credentials \ 653 aws s3 cp s3://... ... 654 ``` 655 656 ```console 657 $ docker buildx build --secret id=aws,src=$HOME/.aws/credentials . 658 ``` 659 660 #### `env` 661 662 Attribute keys: 663 664 - `id` - ID of the secret. Defaults to `env` name. 665 - `env` - Secret environment variable. `id` used if unset, otherwise will look for `src`, `source` if `id` unset. 666 667 ```dockerfile 668 # syntax=docker/dockerfile:1 669 FROM node:alpine 670 RUN --mount=type=bind,target=. \ 671 --mount=type=secret,id=SECRET_TOKEN \ 672 SECRET_TOKEN=$(cat /run/secrets/SECRET_TOKEN) yarn run test 673 ``` 674 675 ```console 676 $ SECRET_TOKEN=token docker buildx build --secret id=SECRET_TOKEN . 677 ``` 678 679 ### <a name="shm-size"></a> Shared memory size for build containers (--shm-size) 680 681 Sets the size of the shared memory allocated for build containers when using 682 `RUN` instructions. 683 684 The format is `<number><unit>`. `number` must be greater than `0`. Unit is 685 optional and can be `b` (bytes), `k` (kilobytes), `m` (megabytes), or `g` 686 (gigabytes). If you omit the unit, the system uses bytes. 687 688 > **Note** 689 > 690 > In most cases, it is recommended to let the builder automatically determine 691 > the appropriate configurations. Manual adjustments should only be considered 692 > when specific performance tuning is required for complex build scenarios. 693 694 ### <a name="ssh"></a> SSH agent socket or keys to expose to the build (--ssh) 695 696 ```text 697 --ssh=default|<id>[=<socket>|<key>[,<key>]] 698 ``` 699 700 This can be useful when some commands in your Dockerfile need specific SSH 701 authentication (e.g., cloning a private repository). 702 703 `--ssh` exposes SSH agent socket or keys to the build and can be used with the 704 [`RUN --mount=type=ssh` mount](https://docs.docker.com/reference/dockerfile/#run---mounttypessh). 705 706 Example to access Gitlab using an SSH agent socket: 707 708 ```dockerfile 709 # syntax=docker/dockerfile:1 710 FROM alpine 711 RUN apk add --no-cache openssh-client 712 RUN mkdir -p -m 0700 ~/.ssh && ssh-keyscan gitlab.com >> ~/.ssh/known_hosts 713 RUN --mount=type=ssh ssh -q -T git@gitlab.com 2>&1 | tee /hello 714 # "Welcome to GitLab, @GITLAB_USERNAME_ASSOCIATED_WITH_SSHKEY" should be printed here 715 # with the type of build progress is defined as `plain`. 716 ``` 717 718 ```console 719 $ eval $(ssh-agent) 720 $ ssh-add ~/.ssh/id_rsa 721 (Input your passphrase here) 722 $ docker buildx build --ssh default=$SSH_AUTH_SOCK . 723 ``` 724 725 ### <a name="ulimit"></a> Set ulimits (--ulimit) 726 727 `--ulimit` overrides the default ulimits of build's containers when using `RUN` 728 instructions and are specified with a soft and hard limit as such: 729 `<type>=<soft limit>[:<hard limit>]`, for example: 730 731 ```console 732 $ docker buildx build --ulimit nofile=1024:1024 . 733 ``` 734 735 > **Note** 736 > 737 > If you don't provide a `hard limit`, the `soft limit` is used 738 > for both values. If no `ulimits` are set, they're inherited from 739 > the default `ulimits` set on the daemon. 740 741 > **Note** 742 > 743 > In most cases, it is recommended to let the builder automatically determine 744 > the appropriate configurations. Manual adjustments should only be considered 745 > when specific performance tuning is required for complex build scenarios.