docker
/
docs
mirror of https://github.com/docker/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #18116 from dvdksn/build-tier1-freshness 

build: tier 1 docs freshness
This commit is contained in:
David Karlsson 2023-09-07 17:29:27 +02:00 committed by GitHub
parent 0bd9426372 63fd22cd50
commit b80744c552
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
49 changed files with 1001 additions and 1224 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
content/build/attestations/_index.md
View File

@ -1,16 +1,11 @@
--- ---
title: Build attestations title: Build attestations
keywords: build, attestations, sbom, provenance keywords: build, attestations, sbom, provenance, metadata
description: 'Introduction to SBOM and provenance attestations with Docker Build; description: |
what they are and why they exist Introduction to SBOM and provenance attestations with Docker Build,
what they are, and why they exist
'
--- ---
> **Note**
>
> This feature is supported in BuildKit version `>=0.11` and Buildx version `>=0.10`.
Build attestations describe how an image was built, and what it contains. The Build attestations describe how an image was built, and what it contains. The
attestations are created at build-time by BuildKit, and become attached to the attestations are created at build-time by BuildKit, and become attached to the
final image as metadata. final image as metadata.
@ -67,11 +62,8 @@ index in a manifest for the final image.
## Storage ## Storage
<!-- prettier-ignore --> BuildKit produces attestations in the [in-toto format](https://github.com/in-toto/attestation),
BuildKit produces attestations in the as defined by the [in-toto framework](https://in-toto.io/),
[in-toto format](https://github.com/in-toto/attestation),
as defined by the
[in-toto framework](https://in-toto.io/),
a standard supported by the Linux Foundation. a standard supported by the Linux Foundation.
Attestations attach to images as a manifest in the image index. The data records Attestations attach to images as a manifest in the image index. The data records
@ -149,7 +141,6 @@ attestation.
} }
``` ```
<!-- prettier-ignore -->
To deep-dive into the specifics about how attestations are stored, see To deep-dive into the specifics about how attestations are stored, see
[Image Attestation Storage (BuildKit)](attestation-storage.md). [Image Attestation Storage (BuildKit)](attestation-storage.md).
@ -158,4 +149,4 @@ To deep-dive into the specifics about how attestations are stored, see
Learn more about the available attestation types and how to use them: Learn more about the available attestation types and how to use them:
- [Provenance](slsa-provenance.md) - [Provenance](slsa-provenance.md)
- [SBOM](sbom.md) - [SBOM](sbom.md)

18
content/build/attestations/sbom.md
View File

@ -1,13 +1,11 @@
--- ---
title: SBOM attestations title: SBOM attestations
keywords: build, attestations, sbom keywords: build, attestations, sbom, spdx, metadata, packages
description: SBOM build attestations description: |
SBOM build attestations describe the contents of your image,
and the packages used to build it.
--- ---
> **Note**
>
> This feature is supported in BuildKit version `>=0.11` and Buildx version `>=0.10`.
Software Bill of Materials (SBOM) attestations describe what software artifacts Software Bill of Materials (SBOM) attestations describe what software artifacts
an image contains, and artifacts used to create the image. Metadata included in an image contains, and artifacts used to create the image. Metadata included in
an SBOM for describing software artifacts may include: an SBOM for describing software artifacts may include:
@ -161,7 +159,7 @@ includes the information that Alpine Linux and Hugo were used to create the webs
Building this image with the `local` exporter creates two JSON files: Building this image with the `local` exporter creates two JSON files:
```console ```console
$ docker buildx build \ $ docker buildx build \
--sbom=true \ --sbom=true \
--output type=local,dest=out . --output type=local,dest=out .
$ ls -1 out | grep sbom $ ls -1 out | grep sbom
@ -178,7 +176,6 @@ Using the `--format` option, you can specify a template for the output. All
SBOM-related data is available under the `.SBOM` attribute. For example, to get SBOM-related data is available under the `.SBOM` attribute. For example, to get
the raw contents of an SBOM in SPDX format: the raw contents of an SBOM in SPDX format:
```console ```console
$ docker buildx imagetools inspect <namespace>/<image>:<version> \ $ docker buildx imagetools inspect <namespace>/<image>:<version> \
--format "{{ json .SBOM.SPDX }}" --format "{{ json .SBOM.SPDX }}"
@ -188,12 +185,10 @@ $ docker buildx imagetools inspect <namespace>/<image>:<version> \
} }
``` ```
You can also construct more complex expressions using the full functionality You can also construct more complex expressions using the full functionality
of Go templates. For example, you can list all the installed packages and their of Go templates. For example, you can list all the installed packages and their
version identifiers: version identifiers:
```console ```console
$ docker buildx imagetools inspect <namespace>/<image>:<version> \ $ docker buildx imagetools inspect <namespace>/<image>:<version> \
--format "{{ range .SBOM.SPDX.packages }}{{ .name }}@{{ .versionInfo }}{{ println }}{{ end }}" --format "{{ range .SBOM.SPDX.packages }}{{ .name }}@{{ .versionInfo }}{{ println }}{{ end }}"
@ -204,7 +199,6 @@ base-passwd@3.5.47
... ...
``` ```
## SBOM generator ## SBOM generator
BuildKit generates the SBOM using a scanner plugin. By default, it uses is the BuildKit generates the SBOM using a scanner plugin. By default, it uses is the
@ -324,4 +318,4 @@ The following JSON example shows what an SBOM attestation might look like.
"spdxVersion": "SPDX-2.2" "spdxVersion": "SPDX-2.2"
} }
} }
``` ```

15
content/build/attestations/slsa-provenance.md
View File

@ -1,13 +1,10 @@
--- ---
title: Provenance attestations title: Provenance attestations
keywords: build, attestations, provenance, slsa keywords: build, attestations, provenance, slsa, git, metadata
description: Provenance build attestations description: >
Provenance build attestations describe how and where your image was built.
--- ---
> **Note**
>
> This feature is supported in BuildKit version `>=0.11` and Buildx version `>=0.10`.
The provenance attestations include facts about the build process, including The provenance attestations include facts about the build process, including
details such as: details such as:
@ -153,7 +150,6 @@ Using the `--format` option, you can specify a template for the output. All
provenance-related data is available under the `.Provenance` attribute. For provenance-related data is available under the `.Provenance` attribute. For
example, to get the raw contents of the Provenance in the SLSA format: example, to get the raw contents of the Provenance in the SLSA format:
```console ```console
$ docker buildx imagetools inspect <namespace>/<image>:<version> \ $ docker buildx imagetools inspect <namespace>/<image>:<version> \
--format "{{ json .Provenance.SLSA }}" --format "{{ json .Provenance.SLSA }}"
@ -163,12 +159,10 @@ $ docker buildx imagetools inspect <namespace>/<image>:<version> \
} }
``` ```
You can also construct more complex expressions using the full functionality of You can also construct more complex expressions using the full functionality of
Go templates. For example, for provenance generated with `mode=max`, you can Go templates. For example, for provenance generated with `mode=max`, you can
extract the full source code of the Dockerfile used to build the image: extract the full source code of the Dockerfile used to build the image:
```console ```console
$ docker buildx imagetools inspect <namespace>/<image>:<version> \ $ docker buildx imagetools inspect <namespace>/<image>:<version> \
--format '{{ range (index .Provenance.SLSA.metadata "https://mobyproject.org/buildkit@v1#metadata").source.infos }}{{ if eq .filename "Dockerfile" }}{{ .data }}{{ end }}{{ end }}' | base64 -d --format '{{ range (index .Provenance.SLSA.metadata "https://mobyproject.org/buildkit@v1#metadata").source.infos }}{{ if eq .filename "Dockerfile" }}{{ .data }}{{ end }}{{ end }}' | base64 -d
@ -177,7 +171,6 @@ RUN apt-get update
... ...
``` ```
## Provenance attestation example ## Provenance attestation example
<!-- TODO: add a link to the definitions page, imported from moby/buildkit --> <!-- TODO: add a link to the definitions page, imported from moby/buildkit -->
@ -351,4 +344,4 @@ attestation with `mode=max` looks like:
} }
} }
} }
``` ```

50
content/build/bake/_index.md
View File

@ -2,40 +2,36 @@
title: High-level builds with Bake title: High-level builds with Bake
keywords: build, buildx, bake, buildkit, hcl, json, compose keywords: build, buildx, bake, buildkit, hcl, json, compose
aliases: aliases:
- /build/customize/bake/ - /build/customize/bake/
--- ---
> This command is experimental. > **Experimental**
> >
> The design of bake is in early stages, and we are looking for [feedback from users](https://github.com/docker/buildx/issues). > Bake is an experimental feature, and we are looking for
> [feedback from users](https://github.com/docker/buildx/issues).
{ .experimental } { .experimental }
Buildx also aims to provide support for high-level build concepts that go beyond Buildx provides support for high-level build orchestration that goes beyond
invoking a single build command. We want to support building all the images in invoking a single build command. Bake lets you build all the images in your
your application together and let the users define project specific reusable application together. You can define all of the build jobs for your projects in
build flows that can then be easily invoked by anyone. a file that can then be easily invoked by anyone.
[BuildKit](https://github.com/moby/buildkit) You can think of Bake as a task runner for Docker builds.
efficiently handles multiple concurrent build requests and de-duplicating work. [BuildKit](https://github.com/moby/buildkit) efficiently handles multiple
The build commands can be combined with general-purpose command runners concurrent build requests and de-duplicating work. You can invoke your builds
(for example, `make`). However, these tools generally invoke builds in sequence using general-purpose task runners, like `make`. However, such tools generally
and therefore cannot leverage the full potential of BuildKit parallelization, invoke builds in a sequence. Therefore they aren't leveraging the full
or combine BuildKit's output for the user. For this use case, we have added a potential of BuildKit parallelization. Bake solves this problem.
command called [`docker buildx bake`](../../engine/reference/commandline/buildx_bake.md).
The `bake` command supports building images from HCL, JSON and Compose files. The `docker buildx bake` command supports building images from a configuration
This is similar to [`docker compose build`](../../compose/compose-file/build.md), file in HCL, JSON or YAML format. The YAML format extends the Compose
but allowing all the services to be built concurrently as part of a single Specification, and it's similar to `docker compose build`, except it builds all
request. If multiple files are specified they are all read and configurations are of your services concurrently as part of a single request.
combined.
We recommend using HCL files as its experience is more aligned with buildx UX
and also allows better code reuse, different target groups and extended features.
## Next steps ## Next steps
* [Bake file reference](reference.md) - [Bake file reference](./reference.md)
* [Configuring builds](configuring-build.md) - [Configuring builds](./configuring-build.md)
* [User defined HCL functions](hcl-funcs.md) - [User defined HCL functions](./advanced.md)
* [Defining additional build contexts and linking targets](build-contexts.md) - [Defining additional build contexts and linking targets](./build-contexts.md)
* [Building from Compose file](compose-file.md) - [Building from Compose file](./compose-file.md)

121
content/build/bake/hcl-funcs.md → content/build/bake/advanced.md
View File

@ -1,15 +1,35 @@
--- ---
title: User defined HCL functions title: Advanced Bake patterns and functions
description: Learn about advanced Bake features, like user-defined functions
keywords: build, buildx, bake, buildkit, hcl keywords: build, buildx, bake, buildkit, hcl
aliases: aliases:
- /build/customize/bake/hcl-funcs/ - /build/customize/bake/hcl-funcs/
- /build/bake/hcl-funcs/
--- ---
## Using interpolation to tag an image with the git sha HCL functions are great for when you need to manipulate values in more complex ways than just concatenating or appending values.
As shown in the [Bake file reference](reference.md#variable) page, `bake` The following sections contain some examples on custom functions and other
advanced use cases:
- [Interpolate environment variables](#interpolate-environment-variables)
- [Built-in functions](#built-in-functions)
- [User-defined functions](#user-defined-functions)
- [Ternary operators](#ternary-operators)
- [Variables in functions](#variables-in-functions)
- [Typed variables](#typed-variables)
## Interpolate environment variables
As shown in the [Bake file reference](reference.md#variable) page, Bake
supports variable blocks which are assigned to matching environment variables supports variable blocks which are assigned to matching environment variables
or default values: or default values.
The following example shows how you can interpolate a `TAG` environment
variable to populate a variable in the Bake configuration.
{{< tabs >}}
{{< tab name="HCL" >}}
```hcl ```hcl
# docker-bake.hcl # docker-bake.hcl
@ -26,7 +46,8 @@ target "webapp" {
} }
``` ```
alternatively, in json format: {{< /tab >}}
{{< tab name="JSON" >}}
```json ```json
{ {
@ -48,6 +69,9 @@ alternatively, in json format:
} }
``` ```
{{< /tab >}}
{{< /tabs >}}
```console ```console
$ docker buildx bake --print webapp $ docker buildx bake --print webapp
``` ```
@ -56,18 +80,14 @@ $ docker buildx bake --print webapp
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["webapp"]
"webapp"
]
} }
}, },
"target": { "target": {
"webapp": { "webapp": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile", "dockerfile": "Dockerfile",
"tags": [ "tags": ["docker.io/username/webapp:latest"]
"docker.io/username/webapp:latest"
]
} }
} }
} }
@ -81,27 +101,23 @@ $ TAG=$(git rev-parse --short HEAD) docker buildx bake --print webapp
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["webapp"]
"webapp"
]
} }
}, },
"target": { "target": {
"webapp": { "webapp": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile", "dockerfile": "Dockerfile",
"tags": [ "tags": ["docker.io/username/webapp:985e9e9"]
"docker.io/username/webapp:985e9e9"
]
} }
} }
} }
``` ```
## Using the `add` function ## Built-in functions
You can use [`go-cty` stdlib functions](https://github.com/zclconf/go-cty/tree/main/cty/function/stdlib). You can use [`go-cty` standard library functions](https://github.com/zclconf/go-cty/tree/main/cty/function/stdlib).
Here we are using the `add` function. The following example shows the `add` function.
```hcl ```hcl
# docker-bake.hcl # docker-bake.hcl
@ -128,9 +144,7 @@ $ docker buildx bake --print webapp
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["webapp"]
"webapp"
]
} }
}, },
"target": { "target": {
@ -145,10 +159,13 @@ $ docker buildx bake --print webapp
} }
``` ```
## Defining an `increment` function ## User-defined functions
It also supports [user defined functions](https://github.com/hashicorp/hcl/tree/main/ext/userfunc). You can create [user-defined functions](https://github.com/hashicorp/hcl/tree/main/ext/userfunc)
The following example defines a simple an `increment` function. that do just what you want, if the built-in standard library functions don't
meet your needs.
The following example defines an `increment` function.
```hcl ```hcl
# docker-bake.hcl # docker-bake.hcl
@ -176,9 +193,7 @@ $ docker buildx bake --print webapp
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["webapp"]
"webapp"
]
} }
}, },
"target": { "target": {
@ -193,10 +208,12 @@ $ docker buildx bake --print webapp
} }
``` ```
## Only adding tags if a variable is not empty using an `notequal` ## Ternary operators
Here we are using the conditional `notequal` function which is just for You can use ternary operators to conditionally register a value.
symmetry with the `equal` one.
The following example adds a tag only when a variable is not empty, using the
`notequal` function.
```hcl ```hcl
# docker-bake.hcl # docker-bake.hcl
@ -226,27 +243,25 @@ $ docker buildx bake --print webapp
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["webapp"]
"webapp"
]
} }
}, },
"target": { "target": {
"webapp": { "webapp": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile", "dockerfile": "Dockerfile",
"tags": [ "tags": ["my-image:latest"]
"my-image:latest"
]
} }
} }
} }
``` ```
## Using variables in functions ## Variables in functions
You can refer variables to other variables like the target blocks can. Stdlib You can make references to variables and standard library functions inside your
functions can also be called but user functions can't at the moment. functions.
You can't reference user-defined functions from other functions.
```hcl ```hcl
# docker-bake.hcl # docker-bake.hcl
@ -272,27 +287,23 @@ $ docker buildx bake --print webapp
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["webapp"]
"webapp"
]
} }
}, },
"target": { "target": {
"webapp": { "webapp": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile", "dockerfile": "Dockerfile",
"tags": [ "tags": ["user/repo:v1"]
"user/repo:v1"
]
} }
} }
} }
``` ```
## Using typed variables ## Typed variables
Non-string variables are also accepted. The value passed with env is parsed Non-string variables are supported. Values passed as environment variables are
into suitable type first. coerced into suitable types first.
```hcl ```hcl
# docker-bake.hcl # docker-bake.hcl
@ -306,7 +317,7 @@ variable "IS_FOO" {
target "app" { target "app" {
args = { args = {
v1 = FOO > 5 ? "higher" : "lower" v1 = FOO > 5 ? "higher" : "lower"
v2 = IS_FOO ? "yes" : "no" v2 = IS_FOO ? "yes" : "no"
} }
} }
@ -320,9 +331,7 @@ $ docker buildx bake --print app
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["app"]
"app"
]
} }
}, },
"target": { "target": {
@ -336,4 +345,4 @@ $ docker buildx bake --print app
} }
} }
} }
``` ```

30
content/build/bake/build-contexts.md
View File

@ -1,18 +1,28 @@
--- ---
title: Defining additional build contexts and linking targets title: Defining additional build contexts and linking targets
description: |
Additional contexts are useful when you want to pin image versions,
or reference the output of other targets
keywords: build, buildx, bake, buildkit, hcl keywords: build, buildx, bake, buildkit, hcl
aliases: aliases:
- /build/customize/bake/build-contexts/ - /build/customize/bake/build-contexts/
--- ---
In addition to the main `context` key that defines the build context each target In addition to the main `context` key that defines the build context, each
can also define additional named contexts with a map defined with key `contexts`. target can also define additional named contexts with a map defined with key
These values map to the `--build-context` flag in the [build command](../../engine/reference/commandline/buildx_build.md#build-context). `contexts`. These values map to the `--build-context` flag in the [build
command](../../engine/reference/commandline/buildx_build.md#build-context).
Inside the Dockerfile these contexts can be used with the `FROM` instruction or `--from` flag. Inside the Dockerfile these contexts can be used with the `FROM` instruction or
`--from` flag.
The value can be a local source directory, container image (with `docker-image://` prefix), Supported context values are:
Git URL, HTTP URL or a name of another target in the Bake file (with `target:` prefix).
- Local filesystem directories
- Container images
- Git URLs
- HTTP URLs
- Name of another target in the Bake file
## Pinning alpine image ## Pinning alpine image
@ -74,6 +84,6 @@ target "app" {
} }
``` ```
Please note that in most cases you should just use a single multi-stage In most cases you should just use a single multi-stage Dockerfile with multiple
Dockerfile with multiple targets for similar behavior. This case is recommended targets for similar behavior. This case is only recommended when you have
when you have multiple Dockerfiles that can't be easily merged into one. multiple Dockerfiles that can't be easily merged into one.

131
content/build/bake/compose-file.md
View File

@ -1,8 +1,9 @@
--- ---
title: Building from Compose file title: Building with Bake from a Compose file
keywords: build, buildx, bake, buildkit, compose description: Build your compose services with Bake
keywords: build, buildx, bake, buildkit, compose, yaml
aliases: aliases:
- /build/customize/bake/compose-file/ - /build/customize/bake/compose-file/
--- ---
## Specification ## Specification
@ -13,7 +14,7 @@ parse a compose file and translate each service to a [target](reference.md#targe
```yaml ```yaml
# docker-compose.yml # docker-compose.yml
services: services:
webapp-dev: webapp-dev:
build: &build-dev build: &build-dev
dockerfile: Dockerfile.webapp dockerfile: Dockerfile.webapp
tags: tags:
@ -45,50 +46,29 @@ $ docker buildx bake --print
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["db", "webapp-dev", "webapp-release"]
"db",
"webapp-dev",
"webapp-release"
]
} }
}, },
"target": { "target": {
"db": { "db": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile.db", "dockerfile": "Dockerfile.db",
"tags": [ "tags": ["docker.io/username/db"]
"docker.io/username/db"
]
}, },
"webapp-dev": { "webapp-dev": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile.webapp", "dockerfile": "Dockerfile.webapp",
"tags": [ "tags": ["docker.io/username/webapp:latest"],
"docker.io/username/webapp:latest" "cache-from": ["docker.io/username/webapp:cache"],
], "cache-to": ["docker.io/username/webapp:cache"]
"cache-from": [
"docker.io/username/webapp:cache"
],
"cache-to": [
"docker.io/username/webapp:cache"
]
}, },
"webapp-release": { "webapp-release": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile.webapp", "dockerfile": "Dockerfile.webapp",
"tags": [ "tags": ["docker.io/username/webapp:latest"],
"docker.io/username/webapp:latest" "cache-from": ["docker.io/username/webapp:cache"],
], "cache-to": ["docker.io/username/webapp:cache"],
"cache-from": [ "platforms": ["linux/amd64", "linux/arm64"]
"docker.io/username/webapp:cache"
],
"cache-to": [
"docker.io/username/webapp:cache"
],
"platforms": [
"linux/amd64",
"linux/arm64"
]
} }
} }
} }
@ -96,9 +76,9 @@ $ docker buildx bake --print
The compose format has some limitations compared to the HCL format: The compose format has some limitations compared to the HCL format:
* Specifying variables or global scope attributes is not yet supported - Specifying variables or global scope attributes is not yet supported
* `inherits` service field is not supported, but you can use [YAML anchors](../../compose/compose-file/10-fragments.md) - `inherits` service field is not supported, but you can use [YAML anchors](../../compose/compose-file/10-fragments.md)
to reference other services like the example above to reference other services, as demonstrated in the previous example with `&build-dev`.
## `.env` file ## `.env` file
@ -129,18 +109,14 @@ $ docker buildx bake --print
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["webapp"]
"webapp"
]
} }
}, },
"target": { "target": {
"webapp": { "webapp": {
"context": ".", "context": ".",
"dockerfile": "Dockerfile", "dockerfile": "Dockerfile",
"tags": [ "tags": ["docker.io/username/webapp:v1.1.0"]
"docker.io/username/webapp:v1.1.0"
]
} }
} }
} }
@ -153,9 +129,9 @@ $ docker buildx bake --print
## Extension field with `x-bake` ## Extension field with `x-bake`
Even if some fields are not (yet) available in the compose specification, you Where some fields are not available in the compose specification, you can use
can use the [special extension](../../compose/compose-file/11-extension.md) the [special extension](../../compose/compose-file/11-extension.md) field
field `x-bake` in your compose file to evaluate extra fields: `x-bake` in your compose file to evaluate extra fields:
```yaml ```yaml
# docker-compose.yml # docker-compose.yml
@ -206,10 +182,7 @@ $ docker buildx bake --print
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["aws", "addon"]
"aws",
"addon"
]
} }
}, },
"target": { "target": {
@ -220,21 +193,10 @@ $ docker buildx bake --print
"CT_ECR": "foo", "CT_ECR": "foo",
"CT_TAG": "bar" "CT_TAG": "bar"
}, },
"tags": [ "tags": ["ct-addon:foo", "ct-addon:alp"],
"ct-addon:foo", "cache-from": ["user/app:cache", "type=local,src=path/to/cache"],
"ct-addon:alp" "cache-to": ["type=local,dest=path/to/cache"],
], "platforms": ["linux/amd64", "linux/arm64"],
"cache-from": [
"user/app:cache",
"type=local,src=path/to/cache"
],
"cache-to": [
"type=local,dest=path/to/cache"
],
"platforms": [
"linux/amd64",
"linux/arm64"
],
"pull": true "pull": true
}, },
"aws": { "aws": {
@ -244,19 +206,10 @@ $ docker buildx bake --print
"CT_ECR": "foo", "CT_ECR": "foo",
"CT_TAG": "bar" "CT_TAG": "bar"
}, },
"tags": [ "tags": ["ct-fake-aws:bar"],
"ct-fake-aws:bar" "secret": ["id=mysecret,src=./secret", "id=mysecret2,src=./secret2"],
], "platforms": ["linux/arm64"],
"secret": [ "output": ["type=docker"],
"id=mysecret,src=./secret",
"id=mysecret2,src=./secret2"
],
"platforms": [
"linux/arm64"
],
"output": [
"type=docker"
],
"no-cache": true "no-cache": true
} }
} }
@ -265,14 +218,14 @@ $ docker buildx bake --print
Complete list of valid fields for `x-bake`: Complete list of valid fields for `x-bake`:
* `cache-from` - `cache-from`
* `cache-to` - `cache-to`
* `contexts` - `contexts`
* `no-cache` - `no-cache`
* `no-cache-filter` - `no-cache-filter`
* `output` - `output`
* `platforms` - `platforms`
* `pull` - `pull`
* `secret` - `secret`
* `ssh` - `ssh`
* `tags` - `tags`

68
content/build/bake/configuring-build.md
View File

@ -1,8 +1,9 @@
--- ---
title: Configuring builds title: Configure builds with Bake
description: Learn how to create a flexible build configuration with Bake
keywords: build, buildx, bake, buildkit, hcl, json keywords: build, buildx, bake, buildkit, hcl, json
aliases: aliases:
- /build/customize/bake/configuring-build/ - /build/customize/bake/configuring-build/
--- ---
Bake supports loading build definitions from files, but sometimes you need even Bake supports loading build definitions from files, but sometimes you need even
@ -43,9 +44,7 @@ $ docker buildx bake --print app
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["app"]
"app"
]
} }
}, },
"target": { "target": {
@ -78,9 +77,7 @@ $ docker buildx bake -f docker-bake.hcl -f env.hcl --print app
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["app"]
"app"
]
} }
}, },
"target": { "target": {
@ -122,26 +119,19 @@ $ docker buildx bake --print foo bar
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["foo", "bar"]
"foo",
"bar"
]
} }
}, },
"target": { "target": {
"foo": { "foo": {
"context": ".", "context": ".",
"dockerfile": "foo.Dockerfile", "dockerfile": "foo.Dockerfile",
"tags": [ "tags": ["foo"]
"foo"
]
}, },
"bar": { "bar": {
"context": ".", "context": ".",
"dockerfile": "foo.Dockerfile", "dockerfile": "foo.Dockerfile",
"tags": [ "tags": ["bar"]
"bar"
]
} }
} }
} }
@ -169,9 +159,7 @@ $ docker buildx bake --set app.args.mybuildarg=bar --set app.platform=linux/arm6
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["app"]
"app"
]
} }
}, },
"target": { "target": {
@ -181,9 +169,7 @@ $ docker buildx bake --set app.args.mybuildarg=bar --set app.platform=linux/arm6
"args": { "args": {
"mybuildarg": "bar" "mybuildarg": "bar"
}, },
"platforms": [ "platforms": ["linux/arm64"]
"linux/arm64"
]
} }
} }
} }
@ -200,20 +186,20 @@ $ docker buildx bake --set foo*.no-cache # bypass caching only for
Complete list of overridable fields: Complete list of overridable fields:
* `args` - `args`
* `cache-from` - `cache-from`
* `cache-to` - `cache-to`
* `context` - `context`
* `dockerfile` - `dockerfile`
* `labels` - `labels`
* `no-cache` - `no-cache`
* `output` - `output`
* `platform` - `platform`
* `pull` - `pull`
* `secrets` - `secrets`
* `ssh` - `ssh`
* `tags` - `tags`
* `target` - `target`
## Using variables in variables across files ## Using variables in variables across files
@ -258,9 +244,7 @@ $ docker buildx bake -f docker-bake1.hcl -f docker-bake2.hcl --print app
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["app"]
"app"
]
} }
}, },
"target": { "target": {
@ -274,4 +258,4 @@ $ docker buildx bake -f docker-bake1.hcl -f docker-bake2.hcl --print app
} }
} }
} }
``` ```

17
content/build/bake/remote-definition.md
View File

@ -1,6 +1,7 @@
--- ---
title: Remote Bake file definition title: Remote Bake file definition
keywords: build, buildx, bake, file, remote description: Build with Bake using a remote file definition using Git or HTTP
keywords: build, buildx, bake, file, remote, git, http
--- ---
You can also build Bake files directly from a remote Git repository or HTTPS URL: You can also build Bake files directly from a remote Git repository or HTTPS URL:
@ -18,9 +19,7 @@ $ docker buildx bake "https://github.com/docker/cli.git#v20.10.11" --print
{ {
"group": { "group": {
"default": { "default": {
"targets": [ "targets": ["binary"]
"binary"
]
} }
}, },
"target": { "target": {
@ -33,12 +32,8 @@ $ docker buildx bake "https://github.com/docker/cli.git#v20.10.11" --print
"VERSION": "" "VERSION": ""
}, },
"target": "binary", "target": "binary",
"platforms": [ "platforms": ["local"],
"local" "output": ["build"]
],
"output": [
"build"
]
} }
} }
} }
@ -133,4 +128,4 @@ $ docker buildx bake "https://github.com/tonistiigi/buildx.git#remote-test" "htt
#8 0.136 drwxrwxrwx 10 root root 4096 Jul 27 18:31 vendor #8 0.136 drwxrwxrwx 10 root root 4096 Jul 27 18:31 vendor
#8 0.136 -rwxrwxrwx 1 root root 9620 Jul 27 18:31 vendor.conf #8 0.136 -rwxrwxrwx 1 root root 9620 Jul 27 18:31 vendor.conf
#8 0.136 /bin/sh: stop: not found #8 0.136 /bin/sh: stop: not found
``` ```

10
content/build/building/base-images.md
View File

@ -1,6 +1,6 @@
--- ---
title: Create a base image title: Create a base image
description: How to create base images description: Learn about base images and how they're created
keywords: images, base image, examples keywords: images, base image, examples
aliases: aliases:
- /articles/baseimages/ - /articles/baseimages/
@ -69,7 +69,7 @@ ADD hello /
CMD ["/hello"] CMD ["/hello"]
``` ```
Assuming you built the "hello" executable example by using the source code at Assuming you built the `hello` executable example by using the source code at
[https://github.com/docker-library/hello-world](https://github.com/docker-library/hello-world), [https://github.com/docker-library/hello-world](https://github.com/docker-library/hello-world),
and you compiled it with the `-static` flag, you can build this Docker and you compiled it with the `-static` flag, you can build this Docker
image using this `docker build` command: image using this `docker build` command:
@ -81,7 +81,9 @@ $ docker build --tag hello .
Don't forget the `.` character at the end, which sets the [build context](../../build/building/context.md) Don't forget the `.` character at the end, which sets the [build context](../../build/building/context.md)
to the current directory. to the current directory.
> **Note**: Because Docker Desktop for Mac and Docker Desktop for Windows use a Linux VM, > **Note**
>
> Because Docker Desktop for Mac and Docker Desktop for Windows use a Linux VM,
> you need a Linux binary, rather than a Mac or Windows binary. > you need a Linux binary, rather than a Mac or Windows binary.
> You can use a Docker container to build it: > You can use a Docker container to build it:
> >
@ -109,4 +111,4 @@ There are lots of resources available to help you write your `Dockerfile`.
* There's a [complete guide to all the instructions](../../engine/reference/builder.md) available for use in a `Dockerfile` in the reference section. * There's a [complete guide to all the instructions](../../engine/reference/builder.md) available for use in a `Dockerfile` in the reference section.
* To help you write a clear, readable, maintainable `Dockerfile`, we've also * To help you write a clear, readable, maintainable `Dockerfile`, we've also
written a [Dockerfile best practices guide](../../develop/develop-images/dockerfile_best-practices.md). written a [Dockerfile best practices guide](../../develop/develop-images/dockerfile_best-practices.md).
* If your goal is to create a new Docker Official Image, read [Docker Official Images](../../docker-hub/official_images.md). * If your goal is to create a new Docker Official Image, read [Docker Official Images](../../docker-hub/official_images.md).

3
content/build/building/opentelemetry.md
View File

@ -1,5 +1,6 @@
--- ---
title: OpenTelemetry support title: OpenTelemetry support
description: Analyze telemetry data for builds
keywords: build, buildx buildkit, opentelemetry keywords: build, buildx buildkit, opentelemetry
--- ---
@ -34,4 +35,4 @@ $ docker buildx inspect --bootstrap
Buildx commands should be traced at `http://127.0.0.1:16686/`: Buildx commands should be traced at `http://127.0.0.1:16686/`:
![OpenTelemetry Buildx Bake](../images/opentelemetry.png) ![OpenTelemetry Buildx Bake](../images/opentelemetry.png)

4
content/build/buildkit/configure.md
View File

@ -144,7 +144,6 @@ The following Dockerfile example shows a custom BuildKit image with CNI support.
It uses the [CNI config for integration tests](https://github.com/moby/buildkit/blob/master//hack/fixtures/cni.json) It uses the [CNI config for integration tests](https://github.com/moby/buildkit/blob/master//hack/fixtures/cni.json)
in BuildKit as an example. Feel free to include your own CNI configuration. in BuildKit as an example. Feel free to include your own CNI configuration.
```dockerfile ```dockerfile
# syntax=docker/dockerfile:1 # syntax=docker/dockerfile:1
@ -166,7 +165,6 @@ COPY --from=cni-plugins /opt/cni/bin /opt/cni/bin
ADD https://raw.githubusercontent.com/moby/buildkit/${BUILDKIT_VERSION}/hack/fixtures/cni.json /etc/buildkit/cni.json ADD https://raw.githubusercontent.com/moby/buildkit/${BUILDKIT_VERSION}/hack/fixtures/cni.json /etc/buildkit/cni.json
``` ```
Now you can build this image, and create a builder instance from it using Now you can build this image, and create a builder instance from it using
[the `--driver-opt image` option](../../engine/reference/commandline/buildx_create.md#driver-opt): [the `--driver-opt image` option](../../engine/reference/commandline/buildx_create.md#driver-opt):
@ -211,4 +209,4 @@ requests. This connection limit prevents your build from getting stuck while
pulling images. The dedicated metadata connection helps reduce the overall build pulling images. The dedicated metadata connection helps reduce the overall build
time. time.
More information: [moby/buildkit#2259](https://github.com/moby/buildkit/pull/2259) More information: [moby/buildkit#2259](https://github.com/moby/buildkit/pull/2259)

59
content/build/cache/_index.md vendored
View File

@ -1,28 +1,20 @@
--- ---
title: Optimizing builds with cache management title: Optimizing builds with cache management
description: Improve your build speeds by taking advantage of the builtin cache description: Improve your build speed with effective use of the build cache
keywords: 'build, buildx, buildkit, dockerfile, image layers, build instructions, keywords: build, buildx, buildkit, dockerfile, image layers, build instructions, build context
build context
'
aliases: aliases:
- /build/building/cache/ - /build/building/cache/
--- ---
You will likely find yourself rebuilding the same Docker image over and over When you build the same Docker image multiple times, knowing how to optimize
again. Whether it's for the next release of your software, or locally during the build cache is a great tool for making sure the builds run fast.
development. Because building images is a common task, Docker provides several
tools that speed up builds.
The most important feature for improving build speeds is Docker's build cache.
## How does the build cache work? ## How does the build cache work?
Understanding Docker's build cache helps you write better Dockerfiles that Understanding Docker's build cache helps you write better Dockerfiles that
result in faster builds. result in faster builds.
Have a look at the following example, which shows a simple Dockerfile for a The following example shows a small Dockerfile for a program written in C.
program written in C.
```dockerfile ```dockerfile
# syntax=docker/dockerfile:1 # syntax=docker/dockerfile:1
@ -34,9 +26,9 @@ WORKDIR /src/
RUN make build RUN make build
``` ```
Each instruction in this Dockerfile translates (roughly) to a layer in your Each instruction in this Dockerfile translates to a layer in your final image.
final image. You can think of image layers as a stack, with each layer adding You can think of image layers as a stack, with each layer adding more content
more content on top of the layers that came before it: on top of the layers that came before it:
![Image layer diagram](../images/cache-stack.png) ![Image layer diagram](../images/cache-stack.png)
@ -73,16 +65,16 @@ anything differently, they still need to re-run.
Now that you understand how the cache works, you can begin to use the cache to Now that you understand how the cache works, you can begin to use the cache to
your advantage. While the cache will automatically work on any `docker build` your advantage. While the cache will automatically work on any `docker build`
that you run, you can often refactor your Dockerfile to get even better that you run, you can often refactor your Dockerfile to get even better
performance. These optimizations can save precious seconds (or even minutes) off performance. These optimizations can save precious seconds (or even minutes)
of your builds. off of your builds.
### Order your layers ### Order your layers
Putting the commands in your Dockerfile into a logical order is a great place to Putting the commands in your Dockerfile into a logical order is a great place
start. Because a change causes a rebuild for steps that follow, try to make to start. Because a change causes a rebuild for steps that follow, try to make
expensive steps appear near the beginning of the Dockerfile. Steps that change expensive steps appear near the beginning of the Dockerfile. Steps that change
often should appear near the end of the Dockerfile, to avoid triggering rebuilds often should appear near the end of the Dockerfile, to avoid triggering
of layers that haven't changed. rebuilds of layers that haven't changed.
Consider the following example. A Dockerfile snippet that runs a JavaScript Consider the following example. A Dockerfile snippet that runs a JavaScript
build from the source files in the current directory: build from the source files in the current directory:
@ -97,8 +89,8 @@ RUN npm build # Run build
``` ```
This Dockerfile is rather inefficient. Updating any file causes a reinstall of This Dockerfile is rather inefficient. Updating any file causes a reinstall of
all dependencies every time you build the Docker image even if the all dependencies every time you build the Docker image even if the dependencies
dependencies didn't change since last time! didn't change since last time!
Instead, the `COPY` command can be split in two. First, copy over the package Instead, the `COPY` command can be split in two. First, copy over the package
management files (in this case, `package.json` and `yarn.lock`). Then, install management files (in this case, `package.json` and `yarn.lock`). Then, install
@ -130,7 +122,7 @@ To get started, here are a few tips and tricks:
Be considerate of what files you add to the image. Be considerate of what files you add to the image.
Running a command like `COPY . /src` will `COPY` your entire [build context](../building/context.md) Running a command like `COPY . /src` will copy your entire [build context](../building/context.md)
into the image. If you've got logs, package manager artifacts, or even previous into the image. If you've got logs, package manager artifacts, or even previous
build results in your current directory, those will also be copied over. This build results in your current directory, those will also be copied over. This
could make your image larger than it needs to be, especially as those files are could make your image larger than it needs to be, especially as those files are
@ -214,13 +206,12 @@ by default.
#### Use multi-stage builds #### Use multi-stage builds
<!-- x-link to multi-stage builds once we have some reworked content for that --> [Multi-stage builds](../building/multi-stage.md) let you split up your
Dockerfile into multiple distinct stages. Each stage completes a step in the
Multi-stage builds let you split up your Dockerfile into multiple distinct build process, and you can bridge the different stages to create your final
stages. Each stage completes a step in the build process, and you can bridge the image at the end. The Docker builder will work out dependencies between the
different stages to create your final image at the end. The Docker builder will stages and run them using the most efficient strategy. This even allows you to
work out dependencies between the stages and run them using the most efficient run multiple builds concurrently.
strategy. This even allows you to run multiple builds concurrently.
Multi-stage builds use two or more `FROM` commands. The following example Multi-stage builds use two or more `FROM` commands. The following example
illustrates building a simple web server that serves HTML from your `docs` illustrates building a simple web server that serves HTML from your `docs`
@ -293,4 +284,4 @@ of continuing.)
For more information on using cache to do efficient builds, see: For more information on using cache to do efficient builds, see:
- [Garbage collection](garbage-collection.md) - [Garbage collection](garbage-collection.md)
- [Cache storage backends](./backends/index.md) - [Cache storage backends](./backends/index.md)

13
content/build/cache/backends/_index.md vendored
View File

@ -1,8 +1,12 @@
--- ---
title: Cache storage backends title: Cache storage backends
descripton: |
Cache backends let you manage your build cache externally.
External cache is useful to create a shared cache that can help
speed up inner loop and CI builds.
keywords: build, buildx, cache, backend, gha, azblob, s3, registry, local keywords: build, buildx, cache, backend, gha, azblob, s3, registry, local
aliases: aliases:
- /build/building/cache/backends/ - /build/building/cache/backends/
--- ---
To ensure fast builds, BuildKit automatically caches the build result in its own To ensure fast builds, BuildKit automatically caches the build result in its own
@ -14,7 +18,7 @@ environments usually have little-to-no persistence between runs, but it's still
important to keep the runtime of image builds as low as possible. important to keep the runtime of image builds as low as possible.
The default `docker` driver supports the `inline` and `local` cache backends. The default `docker` driver supports the `inline` and `local` cache backends.
Other cache backends require you to select an alternative Other cache backends require you to select a different
[driver](../../drivers/index.md). [driver](../../drivers/index.md).
> **Warning** > **Warning**
@ -24,6 +28,7 @@ Other cache backends require you to select an alternative
> [`--secret` option](../../../engine/reference/commandline/buildx_build/#secret). > [`--secret` option](../../../engine/reference/commandline/buildx_build/#secret).
> Manually managing secrets using `COPY` or `ARG` could result in leaked > Manually managing secrets using `COPY` or `ARG` could result in leaked
> credentials. > credentials.
{ .warning }
## Backends ## Backends
@ -32,7 +37,7 @@ Buildx supports the following cache storage backends:
- `inline`: embeds the build cache into the image. - `inline`: embeds the build cache into the image.
The inline cache gets pushed to the same location as the main output result. The inline cache gets pushed to the same location as the main output result.
Note that this only works for the `image` exporter. This only works with the [`image` exporter](../../exporters/image-registry.md).
- `registry`: embeds the build cache into a separate image, and pushes to a - `registry`: embeds the build cache into a separate image, and pushes to a
dedicated location separate from the main output. dedicated location separate from the main output.
@ -162,4 +167,4 @@ $ docker buildx build --push -t <registry>/<image> \
``` ```
This property is only meaningful with the `--cache-to` flag. When fetching This property is only meaningful with the `--cache-to` flag. When fetching
cache, BuildKit will auto-detect the correct media types to use. cache, BuildKit will auto-detect the correct media types to use.

29
content/build/cache/backends/azblob.md vendored
View File

@ -1,28 +1,23 @@
--- ---
title: Azure Blob Storage cache title: Azure Blob Storage cache
description: Manage build cache with Azure blob storage
keywords: build, buildx, cache, backend, azblob, azure keywords: build, buildx, cache, backend, azblob, azure
aliases: aliases:
- /build/building/cache/backends/azblob/ - /build/building/cache/backends/azblob/
--- ---
> **Warning** > **Experimental**
> >
> This cache backend is unreleased. You can use it today, by using the > This is an experimental feature. The interface and behavior are unstable and
> `moby/buildkit:master` image in your Buildx driver. > may change in future releases.
{ .restricted }
The `azblob` cache store uploads your resulting build cache to The `azblob` cache store uploads your resulting build cache to
[Azure's blob storage service](https://azure.microsoft.com/en-us/services/storage/blobs/). [Azure's blob storage service](https://azure.microsoft.com/en-us/services/storage/blobs/).
> **Note** This cache storage backend is not supported with the default `docker` driver.
> To use this feature, create a new builder using a different driver. See
> This cache storage backend requires using a different driver than the default [Build drivers](../../drivers/_index.md) for more information.
> `docker` driver - see more information on selecting a driver
> [here](../../drivers/index.md). To create a new driver (which can act as a
> simple drop-in replacement):
>
> ```console
> $ docker buildx create --use --driver=docker-container
> ```
## Synopsis ## Synopsis
@ -44,7 +39,7 @@ The following table describes the available CSV parameters that you can pass to
| `ignore-error` | `cache-to` | Boolean | `false` | Ignore errors caused by failed cache exports. | | `ignore-error` | `cache-to` | Boolean | `false` | Ignore errors caused by failed cache exports. |
[1]: #authentication [1]: #authentication
[2]: index.md#cache-mode [2]: _index.md#cache-mode
## Authentication ## Authentication
@ -55,7 +50,7 @@ The environment variables are read from the server, not the Buildx client.
## Further reading ## Further reading
For an introduction to caching see [Optimizing builds with cache](../index.md). For an introduction to caching see [Optimizing builds with cache](../_index.md).
For more information on the `azblob` cache backend, see the For more information on the `azblob` cache backend, see the
[BuildKit README](https://github.com/moby/buildkit#azure-blob-storage-cache-experimental). [BuildKit README](https://github.com/moby/buildkit#azure-blob-storage-cache-experimental).

34
content/build/cache/backends/gha.md vendored
View File

@ -1,15 +1,16 @@
--- ---
title: GitHub Actions cache title: GitHub Actions cache
description: Use the GitHub Actions cache to manage your build cache in CI
keywords: build, buildx, cache, backend, gha, github, actions keywords: build, buildx, cache, backend, gha, github, actions
aliases: aliases:
- /build/building/cache/backends/gha/ - /build/building/cache/backends/gha/
--- ---
> **Warning** > **Experimental**
> >
> The GitHub Actions cache is a beta feature. You can use it today, in current > This is an experimental feature. The interface and behavior are unstable and
> releases of Buildx and BuildKit. However, the interface and behavior are > may change in future releases.
> unstable and may change in future releases. { .restricted }
The GitHub Actions cache utilizes the The GitHub Actions cache utilizes the
[GitHub-provided Action's cache](https://github.com/actions/cache) available [GitHub-provided Action's cache](https://github.com/actions/cache) available
@ -17,16 +18,9 @@ from within your CI execution environment. This is the recommended cache to use
inside your GitHub action pipelines, as long as your use case falls within the inside your GitHub action pipelines, as long as your use case falls within the
[size and usage limits set by GitHub](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy). [size and usage limits set by GitHub](https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#usage-limits-and-eviction-policy).
> **Note** This cache storage backend is not supported with the default `docker` driver.
> To use this feature, create a new builder using a different driver. See
> This cache storage backend requires using a different driver than the default [Build drivers](../../drivers/_index.md) for more information.
> `docker` driver - see more information on selecting a driver
> [here](../../drivers/index.md). To create a new driver (which can act as a
> simple drop-in replacement):
>
> ```console
> $ docker buildx create --use --driver=docker-container
> ```
## Synopsis ## Synopsis
@ -49,16 +43,16 @@ The following table describes the available CSV parameters that you can pass to
[1]: #authentication [1]: #authentication
[2]: #scope [2]: #scope
[3]: index.md#cache-mode [3]: _index.md#cache-mode
## Authentication ## Authentication
If the `url` or `token` parameters are left unspecified, the `gha` cache backend If the `url` or `token` parameters are left unspecified, the `gha` cache backend
will fall back to using environment variables. If you invoke the `docker buildx` will fall back to using environment variables. If you invoke the `docker buildx`
command manually from an inline step, then the variables must be manually command manually from an inline step, then the variables must be manually
exposed (using exposed. Consider using the
[`crazy-max/ghaction-github-runtime`](https://github.com/crazy-max/ghaction-github-runtime), [`crazy-max/ghaction-github-runtime`](https://github.com/crazy-max/ghaction-github-runtime),
for example). GitHub Action as a helper for exposing the variables.
## Scope ## Scope
@ -107,10 +101,10 @@ For example:
## Further reading ## Further reading
For an introduction to caching see [Optimizing builds with cache](../index.md). For an introduction to caching see [Optimizing builds with cache](../_index.md).
For more information on the `gha` cache backend, see the For more information on the `gha` cache backend, see the
[BuildKit README](https://github.com/moby/buildkit#github-actions-cache-experimental). [BuildKit README](https://github.com/moby/buildkit#github-actions-cache-experimental).
For more information about using GitHub Actions with Docker, see For more information about using GitHub Actions with Docker, see
[Introduction to GitHub Actions](../../ci/github-actions/index.md) [Introduction to GitHub Actions](../../ci/github-actions/_index.md)

8
content/build/cache/backends/inline.md vendored
View File

@ -1,14 +1,14 @@
--- ---
title: Inline cache title: Inline cache
description: Embed the build cache into the image
keywords: build, buildx, cache, backend, inline keywords: build, buildx, cache, backend, inline
aliases: aliases:
- /build/building/cache/backends/inline/ - /build/building/cache/backends/inline/
--- ---
The `inline` cache storage backend is the simplest way to get an external cache The `inline` cache storage backend is the simplest way to get an external cache
and is easy to get started using if you're already building and pushing an and is easy to get started using if you're already building and pushing an
image. Inline cache is the only cache backend supported by the default `docker` image.
driver.
The downside of inline cache is that it doesn't scale with multi-stage builds The downside of inline cache is that it doesn't scale with multi-stage builds
as well as the other drivers do. It also doesn't offer separation between your as well as the other drivers do. It also doesn't offer separation between your
@ -56,4 +56,4 @@ $ docker buildx build --push -t <registry>/<image> \
For an introduction to caching see [Optimizing builds with cache](../index.md). For an introduction to caching see [Optimizing builds with cache](../index.md).
For more information on the `inline` cache backend, see the For more information on the `inline` cache backend, see the
[BuildKit README](https://github.com/moby/buildkit#inline-push-image-and-cache-together). [BuildKit README](https://github.com/moby/buildkit#inline-push-image-and-cache-together).

15
content/build/cache/backends/local.md vendored
View File

@ -1,8 +1,9 @@
--- ---
title: Local cache title: Local cache
description: Manage build cache with Amazon S3 buckets
keywords: build, buildx, cache, backend, local keywords: build, buildx, cache, backend, local
aliases: aliases:
- /build/building/cache/backends/local/ - /build/building/cache/backends/local/
--- ---
The `local` cache store is a simple cache option that stores your cache as files The `local` cache store is a simple cache option that stores your cache as files
@ -35,13 +36,13 @@ The following table describes the available CSV parameters that you can pass to
| `force-compression` | `cache-to` | `true`,`false` | `false` | Forcibly apply compression, see [cache compression][3]. | | `force-compression` | `cache-to` | `true`,`false` | `false` | Forcibly apply compression, see [cache compression][3]. |
| `ignore-error` | `cache-to` | Boolean | `false` | Ignore errors caused by failed cache exports. | | `ignore-error` | `cache-to` | Boolean | `false` | Ignore errors caused by failed cache exports. |
[1]: index.md#cache-mode [1]: _index.md#cache-mode
[2]: index.md#oci-media-types [2]: _index.md#oci-media-types
[3]: index.md#cache-compression [3]: _index.md#cache-compression
[4]: #cache-versioning [4]: #cache-versioning
If the `src` cache doesn't exist, then the cache import step will fail, but the If the `src` cache doesn't exist, then the cache import step will fail, but the
build will continue. build continues.
## Cache versioning ## Cache versioning
@ -90,7 +91,7 @@ $ docker buildx build --push -t <registry>/<image> \
## Further reading ## Further reading
For an introduction to caching see [Optimizing builds with cache](../index.md). For an introduction to caching see [Optimizing builds with cache](../_index.md).
For more information on the `local` cache backend, see the For more information on the `local` cache backend, see the
[BuildKit README](https://github.com/moby/buildkit#local-directory-1). [BuildKit README](https://github.com/moby/buildkit#local-directory-1).

28
content/build/cache/backends/registry.md vendored
View File

@ -1,8 +1,9 @@
--- ---
title: Registry cache title: Registry cache
description: Manage build cache with an OCI registry
keywords: build, buildx, cache, backend, registry keywords: build, buildx, cache, backend, registry
aliases: aliases:
- /build/building/cache/backends/registry/ - /build/building/cache/backends/registry/
--- ---
The `registry` cache storage can be thought of as an extension to the `inline` The `registry` cache storage can be thought of as an extension to the `inline`
@ -17,16 +18,9 @@ everything that the inline cache can do, and more:
- It works with other exporters for more flexibility, instead of only the - It works with other exporters for more flexibility, instead of only the
`image` exporter. `image` exporter.
> **Note** This cache storage backend is not supported with the default `docker` driver.
> To use this feature, create a new builder using a different driver. See
> This cache storage backend requires using a different driver than the default [Build drivers](../../drivers/_index.md) for more information.
> `docker` driver - see more information on selecting a driver
> [here](../../drivers/index.md). To create a new driver (which can act as a
> simple drop-in replacement):
>
> ```console
> $ docker buildx create --use --driver=docker-container
> ```
## Synopsis ## Synopsis
@ -53,9 +47,9 @@ The following table describes the available CSV parameters that you can pass to
| `force-compression` | `cache-to` | `true`,`false` | `false` | Forcibly apply compression, see [cache compression][3]. | | `force-compression` | `cache-to` | `true`,`false` | `false` | Forcibly apply compression, see [cache compression][3]. |
| `ignore-error` | `cache-to` | Boolean | `false` | Ignore errors caused by failed cache exports. | | `ignore-error` | `cache-to` | Boolean | `false` | Ignore errors caused by failed cache exports. |
[1]: index.md#cache-mode [1]: _index.md#cache-mode
[2]: index.md#oci-media-types [2]: _index.md#oci-media-types
[3]: index.md#cache-compression [3]: _index.md#cache-compression
You can choose any valid value for `ref`, as long as it's not the same as the You can choose any valid value for `ref`, as long as it's not the same as the
target location that you push your image to. You might choose different tags target location that you push your image to. You might choose different tags
@ -65,11 +59,11 @@ target location that you push your image to. You might choose different tags
strategy that you want to use for separating your image from your cache images. strategy that you want to use for separating your image from your cache images.
If the `--cache-from` target doesn't exist, then the cache import step will If the `--cache-from` target doesn't exist, then the cache import step will
fail, but the build will continue. fail, but the build continues.
## Further reading ## Further reading
For an introduction to caching see [Optimizing builds with cache](../index.md). For an introduction to caching see [Optimizing builds with cache](../_index.md).
For more information on the `registry` cache backend, see the For more information on the `registry` cache backend, see the
[BuildKit README](https://github.com/moby/buildkit#registry-push-image-and-cache-separately). [BuildKit README](https://github.com/moby/buildkit#registry-push-image-and-cache-separately).

27
content/build/cache/backends/s3.md vendored
View File

@ -1,29 +1,24 @@
--- ---
title: Amazon S3 cache title: Amazon S3 cache
keywords: build, buildx, cache, backend, s3 description: Manage build cache with Amazon S3 buckets
keywords: build, buildx, cache, backend, s3, buckets, aws
aliases: aliases:
- /build/building/cache/backends/s3/ - /build/building/cache/backends/s3/
--- ---
> **Warning** > **Experimental**
> >
> This cache backend is unreleased. You can use it today, by using the > This is an experimental feature. The interface and behavior are unstable and
> `moby/buildkit:master` image in your Buildx driver. > may change in future releases.
{ .restricted }
The `s3` cache storage uploads your resulting build cache to The `s3` cache storage uploads your resulting build cache to
[Amazon S3 file storage service](https://aws.amazon.com/s3/), [Amazon S3 file storage service](https://aws.amazon.com/s3/),
into a specified bucket. into a specified bucket.
> **Note** This cache storage backend is not supported with the default `docker` driver.
> To use this feature, create a new builder using a different driver. See
> This cache storage backend requires using a different driver than the default [Build drivers](../../drivers/_index.md) for more information.
> `docker` driver - see more information on selecting a driver
> [here](../../drivers/index.md). To create a new driver (which can act as a
> simple drop-in replacement):
>
> ```console
> $ docker buildx create --use --driver=docker-container
> ```
## Synopsis ## Synopsis
@ -64,4 +59,4 @@ The environment variables are read from the server, not the Buildx client.
For an introduction to caching see [Optimizing builds with cache](../index.md). For an introduction to caching see [Optimizing builds with cache](../index.md).
For more information on the `s3` cache backend, see the For more information on the `s3` cache backend, see the
[BuildKit README](https://github.com/moby/buildkit#s3-cache-experimental). [BuildKit README](https://github.com/moby/buildkit#s3-cache-experimental).

28
content/build/cache/garbage-collection.md vendored
View File

@ -1,8 +1,9 @@
--- ---
title: Garbage collection title: Build garbage collection
keywords: build, buildx, buildkit, garbage collection, prune description: Learn about garbage collection in the BuildKit daemon
keywords: build, buildx, buildkit, garbage collection, prune, gc
aliases: aliases:
- /build/building/cache/garbage-collection/ - /build/building/cache/garbage-collection/
--- ---
While [`docker builder prune`](../../engine/reference/commandline/builder_prune.md) While [`docker builder prune`](../../engine/reference/commandline/builder_prune.md)
@ -31,9 +32,9 @@ file:
"enabled": true, "enabled": true,
"defaultKeepStorage": "10GB", "defaultKeepStorage": "10GB",
"policy": [ "policy": [
{"keepStorage": "10GB", "filter": ["unused-for=2200h"]}, { "keepStorage": "10GB", "filter": ["unused-for=2200h"] },
{"keepStorage": "50GB", "filter": ["unused-for=3300h"]}, { "keepStorage": "50GB", "filter": ["unused-for=3300h"] },
{"keepStorage": "100GB", "all": true} { "keepStorage": "100GB", "all": true }
] ]
} }
} }
@ -58,8 +59,7 @@ For other drivers, garbage collection can be configured using the
## Default policies ## Default policies
Default garbage collection policies are applied to all builders if not Default garbage collection policies apply to all builders if not set:
already set:
``` ```
GC Policy rule#0: GC Policy rule#0:
@ -79,14 +79,14 @@ GC Policy rule#3:
Keep Bytes: 26GB Keep Bytes: 26GB
``` ```
* `rule#0`: if build cache uses more than 512MB delete the most easily - `rule#0`: if build cache uses more than 512MB delete the most easily
reproducible data after it has not been used for 2 days. reproducible data after it has not been used for 2 days.
* `rule#1`: remove any data not used for 60 days. - `rule#1`: remove any data not used for 60 days.
* `rule#2`: keep the unshared build cache under cap. - `rule#2`: keep the unshared build cache under cap.
* `rule#3`: if previous policies were insufficient start deleting internal data - `rule#3`: if previous policies were insufficient start deleting internal data
to keep build cache under cap. to keep build cache under cap.
> **Note** > **Note**
> >
> "Keep bytes" defaults to 10% of the size of the disk. If the disk size cannot > `Keep Bytes` defaults to 10% of the size of the disk. If the disk size cannot
> be determined, it defaults to 2GB. > be determined, it uses 2GB as a fallback.

6
content/build/ci/_index.md
View File

@ -1,9 +1,9 @@
--- ---
description: Overview of using Docker for continuous integration description: Using Docker for continuous integration
keywords: ci, build keywords: ci, build
title: Continuous integration with Docker title: Continuous integration with Docker
aliases: aliases:
- /ci-cd/best-practices/ - /ci-cd/best-practices/
--- ---
Continuous Integration (CI) is the part of the development process where you're Continuous Integration (CI) is the part of the development process where you're
@ -55,4 +55,4 @@ that you can use for this purpose.
Docker maintains a set of official GitHub Actions that you can use to build, Docker maintains a set of official GitHub Actions that you can use to build,
annotate, and push container images on the GitHub Actions platform. See annotate, and push container images on the GitHub Actions platform. See
[Introduction to GitHub Actions](./github-actions/index.md) to learn more and [Introduction to GitHub Actions](./github-actions/index.md) to learn more and
get started. get started.

11
content/build/ci/github-actions/_index.md
View File

@ -1,13 +1,10 @@
--- ---
title: Introduction to GitHub Actions title: Introduction to GitHub Actions
description: 'Docker maintains a set of official GitHub Actions for building Docker description: Docker maintains a set of official GitHub Actions for building Docker images.
images.
'
keywords: ci, github actions, gha, build, introduction, tutorial keywords: ci, github actions, gha, build, introduction, tutorial
aliases: aliases:
- /ci-cd/github-actions/ - /ci-cd/github-actions/
- /build/ci/github-actions/examples/ - /build/ci/github-actions/examples/
--- ---
GitHub Actions is a popular CI/CD platform for automating your build, test, and GitHub Actions is a popular CI/CD platform for automating your build, test, and
@ -68,4 +65,4 @@ using the official Docker actions, to build and push an image to Docker Hub.
There are many more things you can do to customize your workflow to better suit There are many more things you can do to customize your workflow to better suit
your needs. To learn more about some of the more advanced use cases, take a look your needs. To learn more about some of the more advanced use cases, take a look
at the advanced examples, such as [building multi-platform images](multi-platform.md), at the advanced examples, such as [building multi-platform images](multi-platform.md),
or [using cache storage backends](cache.md) and also how to [configure your builder](configure-builder.md). or [using cache storage backends](cache.md) and also how to [configure your builder](configure-builder.md).

67
content/build/ci/github-actions/cache.md
View File

@ -8,7 +8,7 @@ Actions.
> **Note** > **Note**
> >
> See [Cache storage backends](../../cache/backends/index.md) for more > See [Cache storage backends](../../cache/backends/_index.md) for more
> details about cache storage backends. > details about cache storage backends.
## Inline cache ## Inline cache
@ -18,7 +18,6 @@ However, note that the `inline` cache exporter only supports `min` cache mode.
To use `max` cache mode, push the image and the cache separately using the To use `max` cache mode, push the image and the cache separately using the
registry cache exporter with the `cache-to` option, as shown in the [registry cache example](#registry-cache). registry cache exporter with the `cache-to` option, as shown in the [registry cache example](#registry-cache).
```yaml ```yaml
name: ci name: ci
@ -31,20 +30,16 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -54,13 +49,11 @@ jobs:
cache-to: type=inline cache-to: type=inline
``` ```
## Registry cache ## Registry cache
You can import/export cache from a cache manifest or (special) image You can import/export cache from a cache manifest or (special) image
configuration on the registry with the [registry cache exporter](../../cache/backends/registry.md). configuration on the registry with the [registry cache exporter](../../cache/backends/registry.md).
```yaml ```yaml
name: ci name: ci
@ -73,20 +66,16 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -96,7 +85,6 @@ jobs:
cache-to: type=registry,ref=user/app:buildcache,mode=max cache-to: type=registry,ref=user/app:buildcache,mode=max
``` ```
## GitHub cache ## GitHub cache
### Cache backend API ### Cache backend API
@ -114,7 +102,6 @@ backend in a GitHub Action workflow, as the `url` (`$ACTIONS_CACHE_URL`) and
`token` (`$ACTIONS_RUNTIME_TOKEN`) attributes only get populated in a workflow `token` (`$ACTIONS_RUNTIME_TOKEN`) attributes only get populated in a workflow
context. context.
```yaml ```yaml
name: ci name: ci
@ -127,20 +114,16 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -150,7 +133,6 @@ jobs:
cache-to: type=gha,mode=max cache-to: type=gha,mode=max
``` ```
### Cache mounts ### Cache mounts
BuildKit doesn't preserve cache mounts in the GitHub Actions cache by default. BuildKit doesn't preserve cache mounts in the GitHub Actions cache by default.
@ -165,7 +147,6 @@ cache mount data with your Docker build steps.
The following example shows how to use this workaround with a Go project. The following example shows how to use this workaround with a Go project.
```yaml ```yaml
name: ci name: ci
on: push on: push
@ -224,7 +205,6 @@ jobs:
cache-source: go-build-cache cache-source: go-build-cache
``` ```
For more information about this workaround, refer to the For more information about this workaround, refer to the
[GitHub repository](https://github.com/overmindtech/buildkit-cache-dance). [GitHub repository](https://github.com/overmindtech/buildkit-cache-dance).
@ -241,7 +221,6 @@ You can also leverage [GitHub cache](https://docs.github.com/en/actions/using-wo
using the [actions/cache](https://github.com/actions/cache) and [local cache exporter](../../cache/backends/local.md) using the [actions/cache](https://github.com/actions/cache) and [local cache exporter](../../cache/backends/local.md)
with this action: with this action:
```yaml ```yaml
name: ci name: ci
@ -254,28 +233,23 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Cache Docker layers
name: Cache Docker layers
uses: actions/cache@v3 uses: actions/cache@v3
with: with:
path: /tmp/.buildx-cache path: /tmp/.buildx-cache
key: ${{ runner.os }}-buildx-${{ github.sha }} key: ${{ runner.os }}-buildx-${{ github.sha }}
restore-keys: | restore-keys: |
${{ runner.os }}-buildx- ${{ runner.os }}-buildx-
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -283,12 +257,11 @@ jobs:
tags: user/app:latest tags: user/app:latest
cache-from: type=local,src=/tmp/.buildx-cache cache-from: type=local,src=/tmp/.buildx-cache
cache-to: type=local,dest=/tmp/.buildx-cache-new,mode=max cache-to: type=local,dest=/tmp/.buildx-cache-new,mode=max
- - # Temp fix
# Temp fix
# https://github.com/docker/build-push-action/issues/252 # https://github.com/docker/build-push-action/issues/252
# https://github.com/moby/buildkit/issues/1896 # https://github.com/moby/buildkit/issues/1896
name: Move cache name: Move cache
run: | run: |
rm -rf /tmp/.buildx-cache rm -rf /tmp/.buildx-cache
mv /tmp/.buildx-cache-new /tmp/.buildx-cache mv /tmp/.buildx-cache-new /tmp/.buildx-cache
``` ```

74
content/build/ci/github-actions/configure-builder.md
View File

@ -49,16 +49,13 @@ jobs:
buildx: buildx:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
buildkitd-flags: --debug buildkitd-flags: --debug
- - name: Build
name: Build
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -89,11 +86,9 @@ jobs:
buildx: buildx:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
config-inline: | config-inline: |
@ -128,11 +123,9 @@ jobs:
buildx: buildx:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
config: .github/buildkitd.toml config: .github/buildkitd.toml
@ -152,7 +145,7 @@ intrinsically linked to GitHub Actions: you can only use strings in the input
fields: fields:
| Name | Type | Description | | Name | Type | Description |
|-------------------|--------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ----------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | String | [Name of the node](../../../engine/reference/commandline/buildx_create.md#node). If empty, it's the name of the builder it belongs to, with an index number suffix. This is useful to set it if you want to modify/remove a node in an underlying step of you workflow. | | `name` | String | [Name of the node](../../../engine/reference/commandline/buildx_create.md#node). If empty, it's the name of the builder it belongs to, with an index number suffix. This is useful to set it if you want to modify/remove a node in an underlying step of you workflow. |
| `endpoint` | String | [Docker context or endpoint](../../../engine/reference/commandline/buildx_create.md#description) of the node to add to the builder | | `endpoint` | String | [Docker context or endpoint](../../../engine/reference/commandline/buildx_create.md#description) of the node to add to the builder |
| `driver-opts` | List | List of additional [driver-specific options](../../../engine/reference/commandline/buildx_create.md#driver-opt) | | `driver-opts` | List | List of additional [driver-specific options](../../../engine/reference/commandline/buildx_create.md#driver-opt) |
@ -162,7 +155,6 @@ fields:
Here is an example using remote nodes with the [`remote` driver](../../drivers/remote.md) Here is an example using remote nodes with the [`remote` driver](../../drivers/remote.md)
and [TLS authentication](#tls-authentication): and [TLS authentication](#tls-authentication):
```yaml ```yaml
name: ci name: ci
@ -173,8 +165,7 @@ jobs:
buildx: buildx:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
driver: remote driver: remote
@ -196,7 +187,6 @@ jobs:
BUILDER_NODE_2_AUTH_TLS_KEY: ${{ secrets.LINUXONE_KEY }} BUILDER_NODE_2_AUTH_TLS_KEY: ${{ secrets.LINUXONE_KEY }}
``` ```
## Authentication for remote builders ## Authentication for remote builders
The following examples show how to handle authentication for remote builders, The following examples show how to handle authentication for remote builders,
@ -207,7 +197,6 @@ using SSH or TLS.
To be able to connect to an SSH endpoint using the [`docker-container` driver](../../drivers/docker-container.md), To be able to connect to an SSH endpoint using the [`docker-container` driver](../../drivers/docker-container.md),
you have to set up the SSH private key and configuration on the GitHub Runner: you have to set up the SSH private key and configuration on the GitHub Runner:
```yaml ```yaml
name: ci name: ci
@ -218,21 +207,18 @@ jobs:
buildx: buildx:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Set up SSH
name: Set up SSH
uses: MrSquaare/ssh-setup-action@523473d91581ccbf89565e12b40faba93f2708bd # v1.1.0 uses: MrSquaare/ssh-setup-action@523473d91581ccbf89565e12b40faba93f2708bd # v1.1.0
with: with:
host: graviton2 host: graviton2
private-key: ${{ secrets.SSH_PRIVATE_KEY }} private-key: ${{ secrets.SSH_PRIVATE_KEY }}
private-key-name: aws_graviton2 private-key-name: aws_graviton2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
endpoint: ssh://me@graviton2 endpoint: ssh://me@graviton2
``` ```
### TLS authentication ### TLS authentication
You can also [set up a remote BuildKit instance](../../drivers/remote.md#example-remote-buildkit-in-docker-container) You can also [set up a remote BuildKit instance](../../drivers/remote.md#example-remote-buildkit-in-docker-container)
@ -246,7 +232,6 @@ certificates for the `tcp://`:
The `<idx>` placeholder is the position of the node in the list of nodes. The `<idx>` placeholder is the position of the node in the list of nodes.
```yaml ```yaml
name: ci name: ci
@ -257,8 +242,7 @@ jobs:
buildx: buildx:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
driver: remote driver: remote
@ -269,7 +253,6 @@ jobs:
BUILDER_NODE_0_AUTH_TLS_KEY: ${{ secrets.GRAVITON2_KEY }} BUILDER_NODE_0_AUTH_TLS_KEY: ${{ secrets.GRAVITON2_KEY }}
``` ```
## Standalone mode ## Standalone mode
If you don't have the Docker CLI installed on the GitHub Runner, the Buildx If you don't have the Docker CLI installed on the GitHub Runner, the Buildx
@ -287,16 +270,13 @@ jobs:
buildx: buildx:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
driver: kubernetes driver: kubernetes
- - name: Build
name: Build
run: | run: |
buildx build . buildx build .
``` ```
@ -315,7 +295,6 @@ hardware.
For more information about remote builder, see [`remote` driver](../../drivers/remote.md) For more information about remote builder, see [`remote` driver](../../drivers/remote.md)
and the [append builder nodes example](#append-additional-nodes-to-the-builder). and the [append builder nodes example](#append-additional-nodes-to-the-builder).
```yaml ```yaml
name: ci name: ci
@ -328,33 +307,26 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - uses: docker/setup-buildx-action@v2
uses: docker/setup-buildx-action@v2
id: builder1 id: builder1
- - uses: docker/setup-buildx-action@v2
uses: docker/setup-buildx-action@v2
id: builder2 id: builder2
- - name: Builder 1 name
name: Builder 1 name
run: echo ${{ steps.builder1.outputs.name }} run: echo ${{ steps.builder1.outputs.name }}
- - name: Builder 2 name
name: Builder 2 name
run: echo ${{ steps.builder2.outputs.name }} run: echo ${{ steps.builder2.outputs.name }}
- - name: Build against builder1
name: Build against builder1
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
builder: ${{ steps.builder1.outputs.name }} builder: ${{ steps.builder1.outputs.name }}
context: . context: .
target: mytarget1 target: mytarget1
- - name: Build against builder2
name: Build against builder2
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
builder: ${{ steps.builder2.outputs.name }} builder: ${{ steps.builder2.outputs.name }}
context: . context: .
target: mytarget2 target: mytarget2
``` ```

25
content/build/ci/github-actions/copy-image-registries.md
View File

@ -1,12 +1,12 @@
--- ---
title: Copy image between registries with GitHub Actions title: Copy image between registries with GitHub Actions
description: Build multi-platform images and copy them between registries with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, registry keywords: ci, github actions, gha, buildkit, buildx, registry
--- ---
[Multi-platform images](../../building/multi-platform.md) built using Buildx can [Multi-platform images](../../building/multi-platform.md) built using Buildx can
be copied from one registry to another using the [`buildx imagetools create` command](../../../engine/reference/commandline/buildx_imagetools_create.md): be copied from one registry to another using the [`buildx imagetools create` command](../../../engine/reference/commandline/buildx_imagetools_create.md):
```yaml ```yaml
name: ci name: ci
@ -19,30 +19,24 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Login to GitHub Container Registry
name: Login to GitHub Container Registry
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
registry: ghcr.io registry: ghcr.io
username: ${{ github.repository_owner }} username: ${{ github.repository_owner }}
password: ${{ secrets.GITHUB_TOKEN }} password: ${{ secrets.GITHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -51,11 +45,10 @@ jobs:
tags: | tags: |
user/app:latest user/app:latest
user/app:1.0.0 user/app:1.0.0
- - name: Push image to GHCR
name: Push image to GHCR
run: | run: |
docker buildx imagetools create \ docker buildx imagetools create \
--tag ghcr.io/user/app:latest \ --tag ghcr.io/user/app:latest \
--tag ghcr.io/user/app:1.0.0 \ --tag ghcr.io/user/app:1.0.0 \
user/app:latest user/app:latest
``` ```

18
content/build/ci/github-actions/export-docker.md
View File

@ -1,12 +1,12 @@
--- ---
title: Export to Docker with GitHub Actions title: Export to Docker with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, docker description: Load the build results to the image store with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, docker, export, load
--- ---
You may want your build result to be available in the Docker client through You may want your build result to be available in the Docker client through
`docker images` to be able to use it in another step of your workflow: `docker images` to be able to use it in another step of your workflow:
```yaml ```yaml
name: ci name: ci
@ -19,21 +19,17 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Build
name: Build
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
load: true load: true
tags: myimage:latest tags: myimage:latest
- - name: Inspect
name: Inspect
run: | run: |
docker image inspect myimage:latest docker image inspect myimage:latest
``` ```

19
content/build/ci/github-actions/local-registry.md
View File

@ -1,12 +1,12 @@
--- ---
title: Local registry with GitHub Actions title: Local registry with GitHub Actions
description: Create and use a local OCI registry with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, registry keywords: ci, github actions, gha, buildkit, buildx, registry
--- ---
For testing purposes you may need to create a [local registry](https://hub.docker.com/_/registry) For testing purposes you may need to create a [local registry](https://hub.docker.com/_/registry)
to push images into: to push images into:
```yaml ```yaml
name: ci name: ci
@ -24,26 +24,21 @@ jobs:
ports: ports:
- 5000:5000 - 5000:5000
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
driver-opts: network=host driver-opts: network=host
- - name: Build and push to local registry
name: Build and push to local registry
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
push: true push: true
tags: localhost:5000/name/app:latest tags: localhost:5000/name/app:latest
- - name: Inspect
name: Inspect
run: | run: |
docker buildx imagetools inspect localhost:5000/name/app:latest docker buildx imagetools inspect localhost:5000/name/app:latest
``` ```

25
content/build/ci/github-actions/manage-tags-labels.md
View File

@ -1,5 +1,6 @@
--- ---
title: Manage tags and labels with GitHub Actions title: Manage tags and labels with GitHub Actions
description: Assign tags and labels to images automatically with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, tags, labels keywords: ci, github actions, gha, buildkit, buildx, tags, labels
--- ---
@ -8,7 +9,6 @@ for labels, you can do it in a dedicated setup step. The following workflow
will use the [Docker Metadata Action](https://github.com/docker/metadata-action) will use the [Docker Metadata Action](https://github.com/docker/metadata-action)
to handle tags and labels based on GitHub Actions events and Git metadata: to handle tags and labels based on GitHub Actions events and Git metadata:
```yaml ```yaml
name: ci name: ci
@ -28,11 +28,9 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Docker meta
name: Docker meta
id: meta id: meta
uses: docker/metadata-action@v4 uses: docker/metadata-action@v4
with: with:
@ -49,33 +47,28 @@ jobs:
type=semver,pattern={{major}}.{{minor}} type=semver,pattern={{major}}.{{minor}}
type=semver,pattern={{major}} type=semver,pattern={{major}}
type=sha type=sha
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
if: github.event_name != 'pull_request' if: github.event_name != 'pull_request'
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Login to GHCR
name: Login to GHCR
if: github.event_name != 'pull_request' if: github.event_name != 'pull_request'
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
registry: ghcr.io registry: ghcr.io
username: ${{ github.repository_owner }} username: ${{ github.repository_owner }}
password: ${{ secrets.GITHUB_TOKEN }} password: ${{ secrets.GITHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
push: ${{ github.event_name != 'pull_request' }} push: ${{ github.event_name != 'pull_request' }}
tags: ${{ steps.meta.outputs.tags }} tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }} labels: ${{ steps.meta.outputs.labels }}
``` ```

65
content/build/ci/github-actions/multi-platform.md
View File

@ -1,5 +1,6 @@
--- ---
title: Multi-platform image with GitHub Actions title: Multi-platform image with GitHub Actions
description: Build for multiple architectures with GitHub Actions using QEMU emulation or multiple native builders
keywords: ci, github actions, gha, buildkit, buildx, multi-platform keywords: ci, github actions, gha, buildkit, buildx, multi-platform
--- ---
@ -13,7 +14,6 @@ the `platforms` option, as shown in the following example:
> - If you want support for more platforms, you can use QEMU with the [Docker Setup QEMU](https://github.com/docker/setup-qemu-action) > - If you want support for more platforms, you can use QEMU with the [Docker Setup QEMU](https://github.com/docker/setup-qemu-action)
> action. > action.
```yaml ```yaml
name: ci name: ci
@ -26,23 +26,18 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -51,7 +46,6 @@ jobs:
tags: user/app:latest tags: user/app:latest
``` ```
## Distribute build across multiple runners ## Distribute build across multiple runners
In the previous example, each platform is built on the same runner which can In the previous example, each platform is built on the same runner which can
@ -68,7 +62,6 @@ create a manifest list and push it to Docker Hub.
This example also uses the [`metadata` action](https://github.com/docker/metadata-action) This example also uses the [`metadata` action](https://github.com/docker/metadata-action)
to set tags and labels. to set tags and labels.
```yaml ```yaml
name: ci name: ci
@ -92,29 +85,23 @@ jobs:
- linux/arm/v7 - linux/arm/v7
- linux/arm64 - linux/arm64
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Docker meta
name: Docker meta
id: meta id: meta
uses: docker/metadata-action@v4 uses: docker/metadata-action@v4
with: with:
images: ${{ env.REGISTRY_IMAGE }} images: ${{ env.REGISTRY_IMAGE }}
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and push by digest
name: Build and push by digest
id: build id: build
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
@ -122,55 +109,47 @@ jobs:
platforms: ${{ matrix.platform }} platforms: ${{ matrix.platform }}
labels: ${{ steps.meta.outputs.labels }} labels: ${{ steps.meta.outputs.labels }}
outputs: type=image,name=${{ env.REGISTRY_IMAGE }},push-by-digest=true,name-canonical=true,push=true outputs: type=image,name=${{ env.REGISTRY_IMAGE }},push-by-digest=true,name-canonical=true,push=true
- - name: Export digest
name: Export digest
run: | run: |
mkdir -p /tmp/digests mkdir -p /tmp/digests
digest="${{ steps.build.outputs.digest }}" digest="${{ steps.build.outputs.digest }}"
touch "/tmp/digests/${digest#sha256:}" touch "/tmp/digests/${digest#sha256:}"
- - name: Upload digest
name: Upload digest
uses: actions/upload-artifact@v3 uses: actions/upload-artifact@v3
with: with:
name: digests name: digests
path: /tmp/digests/* path: /tmp/digests/*
if-no-files-found: error if-no-files-found: error
retention-days: 1 retention-days: 1
merge: merge:
runs-on: ubuntu-latest runs-on: ubuntu-latest
needs: needs:
- build - build
steps: steps:
- - name: Download digests
name: Download digests
uses: actions/download-artifact@v3 uses: actions/download-artifact@v3
with: with:
name: digests name: digests
path: /tmp/digests path: /tmp/digests
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Docker meta
name: Docker meta
id: meta id: meta
uses: docker/metadata-action@v4 uses: docker/metadata-action@v4
with: with:
images: ${{ env.REGISTRY_IMAGE }} images: ${{ env.REGISTRY_IMAGE }}
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Create manifest list and push
name: Create manifest list and push
working-directory: /tmp/digests working-directory: /tmp/digests
run: | run: |
docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \ docker buildx imagetools create $(jq -cr '.tags | map("-t " + .) | join(" ")' <<< "$DOCKER_METADATA_OUTPUT_JSON") \
$(printf '${{ env.REGISTRY_IMAGE }}@sha256:%s ' *) $(printf '${{ env.REGISTRY_IMAGE }}@sha256:%s ' *)
- - name: Inspect image
name: Inspect image
run: | run: |
docker buildx imagetools inspect ${{ env.REGISTRY_IMAGE }}:${{ steps.meta.outputs.version }} docker buildx imagetools inspect ${{ env.REGISTRY_IMAGE }}:${{ steps.meta.outputs.version }}
``` ```

43
content/build/ci/github-actions/named-contexts.md
View File

@ -1,5 +1,6 @@
--- ---
title: Named contexts with GitHub Actions title: Named contexts with GitHub Actions
description: Use additional contexts in multi-stage builds with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, context keywords: ci, github actions, gha, buildkit, buildx, context
--- ---
@ -20,7 +21,6 @@ FROM alpine
RUN echo "Hello World" RUN echo "Hello World"
``` ```
```yaml ```yaml
name: ci name: ci
@ -33,14 +33,11 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Build
name: Build
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -49,7 +46,6 @@ jobs:
tags: myimage:latest tags: myimage:latest
``` ```
## Use image in subsequent steps ## Use image in subsequent steps
By default, the [Docker Setup Buildx](https://github.com/marketplace/actions/docker-setup-buildx) By default, the [Docker Setup Buildx](https://github.com/marketplace/actions/docker-setup-buildx)
@ -64,7 +60,6 @@ FROM alpine
RUN echo "Hello World" RUN echo "Hello World"
``` ```
```yaml ```yaml
name: ci name: ci
@ -77,24 +72,20 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
driver: docker driver: docker
- - name: Build base image
name: Build base image
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: ./base context: ./base
file: ./base/Dockerfile file: ./base/Dockerfile
load: true load: true
tags: my-base-image:latest tags: my-base-image:latest
- - name: Build
name: Build
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -103,7 +94,6 @@ jobs:
tags: myimage:latest tags: myimage:latest
``` ```
## Using with a container builder ## Using with a container builder
As shown in the previous section we are not using the default As shown in the previous section we are not using the default
@ -135,32 +125,27 @@ jobs:
ports: ports:
- 5000:5000 - 5000:5000
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
with: with:
# network=host driver-opt needed to push to local registry # network=host driver-opt needed to push to local registry
driver-opts: network=host driver-opts: network=host
- - name: Build base image
name: Build base image
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: ./base context: ./base
file: ./base/Dockerfile file: ./base/Dockerfile
tags: localhost:5000/my-base-image:latest tags: localhost:5000/my-base-image:latest
push: true push: true
- - name: Build
name: Build
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
build-contexts: | build-contexts: |
alpine=docker-image://localhost:5000/my-base-image:latest alpine=docker-image://localhost:5000/my-base-image:latest
tags: myimage:latest tags: myimage:latest
``` ```

28
content/build/ci/github-actions/push-multi-registries.md
View File

@ -1,11 +1,11 @@
--- ---
title: Push to multi-registries with GitHub Actions title: Push to multiple registries with GitHub Actions
description: Push to multiple registries with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, registry keywords: ci, github actions, gha, buildkit, buildx, registry
--- ---
The following workflow will connect you to Docker Hub and [GitHub Container Registry](https://github.com/docker/login-action#github-container-registry) The following workflow will connect you to Docker Hub and GitHub Container
and push the image to both registries: Registry, and push the image to both registries:
```yaml ```yaml
name: ci name: ci
@ -19,30 +19,24 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Login to GitHub Container Registry
name: Login to GitHub Container Registry
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
registry: ghcr.io registry: ghcr.io
username: ${{ github.repository_owner }} username: ${{ github.repository_owner }}
password: ${{ secrets.GITHUB_TOKEN }} password: ${{ secrets.GITHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -53,4 +47,4 @@ jobs:
user/app:1.0.0 user/app:1.0.0
ghcr.io/user/app:latest ghcr.io/user/app:latest
ghcr.io/user/app:1.0.0 ghcr.io/user/app:1.0.0
``` ```

22
content/build/ci/github-actions/secrets.md
View File

@ -1,5 +1,6 @@
--- ---
title: Using secrets with GitHub Actions title: Using secrets with GitHub Actions
description: Example using secret mounts with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, secret keywords: ci, github actions, gha, buildkit, buildx, secret
--- ---
@ -18,7 +19,6 @@ RUN --mount=type=secret,id=github_token \
In this example, the secret name is `github_token`. The following workflow In this example, the secret name is `github_token`. The following workflow
exposes this secret using the `secrets` input: exposes this secret using the `secrets` input:
```yaml ```yaml
name: ci name: ci
@ -31,17 +31,13 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Build
name: Build
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -51,8 +47,6 @@ jobs:
"github_token=${{ secrets.GITHUB_TOKEN }}" "github_token=${{ secrets.GITHUB_TOKEN }}"
``` ```
> **Note** > **Note**
> >
> You can also expose a secret file to the build with the `secret-files` input: > You can also expose a secret file to the build with the `secret-files` input:
@ -66,7 +60,6 @@ If you're using [GitHub secrets](https://docs.github.com/en/actions/security-gui
and need to handle multi-line value, you will need to place the key-value pair and need to handle multi-line value, you will need to place the key-value pair
between quotes: between quotes:
```yaml ```yaml
secrets: | secrets: |
"MYSECRET=${{ secrets.GPG_KEY }}" "MYSECRET=${{ secrets.GPG_KEY }}"
@ -82,9 +75,8 @@ secrets: |
"JSON_SECRET={""key1"":""value1"",""key2"":""value2""}" "JSON_SECRET={""key1"":""value1"",""key2"":""value2""}"
``` ```
| Key | Value | | Key | Value |
|------------------|-------------------------------------| | ---------------- | ----------------------------------- |
| `MYSECRET` | `***********************` | | `MYSECRET` | `***********************` |
| `GIT_AUTH_TOKEN` | `abcdefghi,jklmno=0123456789` | | `GIT_AUTH_TOKEN` | `abcdefghi,jklmno=0123456789` |
| `MYSECRET` | `aaaaaaaa\nbbbbbbb\nccccccccc` | | `MYSECRET` | `aaaaaaaa\nbbbbbbb\nccccccccc` |
@ -94,4 +86,4 @@ secrets: |
> **Note** > **Note**
> >
> Double escapes are needed for quote signs. > Double escapes are needed for quote signs.

22
content/build/ci/github-actions/share-image-jobs.md
View File

@ -1,5 +1,6 @@
--- ---
title: Share built image between jobs with GitHub Actions title: Share built image between jobs with GitHub Actions
description: Share an image between runners without pushing to a registry
keywords: ci, github actions, gha, buildkit, buildx keywords: ci, github actions, gha, buildkit, buildx
--- ---
@ -10,7 +11,6 @@ in a workflow using the [actions/upload-artifact](https://github.com/actions/upl
and [actions/download-artifact](https://github.com/actions/download-artifact) and [actions/download-artifact](https://github.com/actions/download-artifact)
actions: actions:
```yaml ```yaml
name: ci name: ci
@ -23,21 +23,17 @@ jobs:
build: build:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Build and export
name: Build and export
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
tags: myimage:latest tags: myimage:latest
outputs: type=docker,dest=/tmp/myimage.tar outputs: type=docker,dest=/tmp/myimage.tar
- - name: Upload artifact
name: Upload artifact
uses: actions/upload-artifact@v3 uses: actions/upload-artifact@v3
with: with:
name: myimage name: myimage
@ -47,15 +43,13 @@ jobs:
runs-on: ubuntu-latest runs-on: ubuntu-latest
needs: build needs: build
steps: steps:
- - name: Download artifact
name: Download artifact
uses: actions/download-artifact@v3 uses: actions/download-artifact@v3
with: with:
name: myimage name: myimage
path: /tmp path: /tmp
- - name: Load image
name: Load image
run: | run: |
docker load --input /tmp/myimage.tar docker load --input /tmp/myimage.tar
docker image ls -a docker image ls -a
``` ```

37
content/build/ci/github-actions/test-before-push.md
View File

@ -1,18 +1,17 @@
--- ---
title: Test before push with GitHub Actions title: Test before push with GitHub Actions
description: Here's how you can validate an image, before pushing it to a registry
keywords: ci, github actions, gha, buildkit, buildx, test keywords: ci, github actions, gha, buildkit, buildx, test
--- ---
In some cases, you might want to validate that the image works as expected In some cases, you might want to validate that the image works as expected
before pushing it. before pushing it. The following workflow implements several steps to achieve
this:
The following workflow implements several steps to achieve this:
1. Build and export the image to Docker 1. Build and export the image to Docker
2. Test your image 2. Test your image
3. Multi-platform build and push the image 3. Multi-platform build and push the image
```yaml ```yaml
name: ci name: ci
@ -29,34 +28,27 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and export to Docker
name: Build and export to Docker
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
load: true load: true
tags: ${{ env.TEST_TAG }} tags: ${{ env.TEST_TAG }}
- - name: Test
name: Test
run: | run: |
docker run --rm ${{ env.TEST_TAG }} docker run --rm ${{ env.TEST_TAG }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
@ -65,10 +57,9 @@ jobs:
tags: ${{ env.LATEST_TAG }} tags: ${{ env.LATEST_TAG }}
``` ```
> **Note** > **Note**
> >
> This workflow doesn't actually build the `linux/amd64` image twice. The image > The `linux/amd64` image is only built once in this workflow. The image is
> is built once, and the following steps uses the internal cache for from the > built once, and the following steps use the internal cache from the first
> first `Build and push` step. The second `Build and push` step only builds > `Build and push` step. The second `Build and push` step only builds
> `linux/arm64`. > `linux/arm64`.

24
content/build/ci/github-actions/update-dockerhub-desc.md
View File

@ -1,5 +1,6 @@
--- ---
title: Update Docker Hub repo description with GitHub Actions title: Update Docker Hub description with GitHub Actions
description: How to update the repository README in Docker Hub using with GitHub Actions
keywords: ci, github actions, gha, buildkit, buildx, docker hub keywords: ci, github actions, gha, buildkit, buildx, docker hub
--- ---
@ -7,7 +8,6 @@ You can update the Docker Hub repository description using a third party action
called [Docker Hub Description](https://github.com/peter-evans/dockerhub-description) called [Docker Hub Description](https://github.com/peter-evans/dockerhub-description)
with this action: with this action:
```yaml ```yaml
name: ci name: ci
@ -20,33 +20,27 @@ jobs:
docker: docker:
runs-on: ubuntu-latest runs-on: ubuntu-latest
steps: steps:
- - name: Checkout
name: Checkout
uses: actions/checkout@v3 uses: actions/checkout@v3
- - name: Set up QEMU
name: Set up QEMU
uses: docker/setup-qemu-action@v2 uses: docker/setup-qemu-action@v2
- - name: Set up Docker Buildx
name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2 uses: docker/setup-buildx-action@v2
- - name: Login to Docker Hub
name: Login to Docker Hub
uses: docker/login-action@v2 uses: docker/login-action@v2
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
- - name: Build and push
name: Build and push
uses: docker/build-push-action@v4 uses: docker/build-push-action@v4
with: with:
context: . context: .
push: true push: true
tags: user/app:latest tags: user/app:latest
- - name: Update repo description
name: Update repo description
uses: peter-evans/dockerhub-description@v3 uses: peter-evans/dockerhub-description@v3
with: with:
username: ${{ secrets.DOCKERHUB_USERNAME }} username: ${{ secrets.DOCKERHUB_USERNAME }}
password: ${{ secrets.DOCKERHUB_TOKEN }} password: ${{ secrets.DOCKERHUB_TOKEN }}
repository: user/app repository: user/app
``` ```

13
content/build/dockerfile/frontend.md
View File

@ -1,8 +1,9 @@
--- ---
title: Custom Dockerfile syntax title: Custom Dockerfile syntax
description: Dive deep into the Dockerfile frontend, and learn about custom frontends
keywords: build, buildkit, dockerfile, frontend keywords: build, buildkit, dockerfile, frontend
aliases: aliases:
- /build/buildkit/dockerfile-frontend/ - /build/buildkit/dockerfile-frontend/
--- ---
## Dockerfile frontend ## Dockerfile frontend
@ -38,7 +39,7 @@ Custom Dockerfile implementations allow you to:
- Use [alternative build definitions, or create your own](https://github.com/moby/buildkit#exploring-llb) - Use [alternative build definitions, or create your own](https://github.com/moby/buildkit#exploring-llb)
> **Note** > **Note**
> >
> BuildKit also ships with a built-in Dockerfile frontend, but it's recommended > BuildKit also ships with a built-in Dockerfile frontend, but it's recommended
> to use an external image to make sure that all users use the same version on > to use an external image to make sure that all users use the same version on
> the builder and to pick up bugfixes automatically without waiting for a new > the builder and to pick up bugfixes automatically without waiting for a new
@ -57,7 +58,7 @@ For example:
- `docker/dockerfile:1` - kept updated with the latest `1.x.x` minor _and_ patch - `docker/dockerfile:1` - kept updated with the latest `1.x.x` minor _and_ patch
release. release.
- `docker/dockerfile:1.2` - kept updated with the latest `1.2.x` patch release, - `docker/dockerfile:1.2` - kept updated with the latest `1.2.x` patch release,
and stops receiving updates once version `1.3.0` is released. and stops receiving updates once version `1.3.0` is released.
- `docker/dockerfile:1.2.1` - immutable: never updated. - `docker/dockerfile:1.2.1` - immutable: never updated.
@ -82,7 +83,7 @@ suffix, for example:
- `docker/dockerfile:labs` - latest release on `labs` channel. - `docker/dockerfile:labs` - latest release on `labs` channel.
- `docker/dockerfile:1-labs` - same as `dockerfile:1`, with experimental - `docker/dockerfile:1-labs` - same as `dockerfile:1`, with experimental
features enabled. features enabled.
- `docker/dockerfile:1.2-labs` - same as `dockerfile:1.2`, with experimental - `docker/dockerfile:1.2-labs` - same as `dockerfile:1.2`, with experimental
features enabled. features enabled.
- `docker/dockerfile:1.2.1-labs` - immutable: never updated. Same as - `docker/dockerfile:1.2.1-labs` - immutable: never updated. Same as
`dockerfile:1.2.1`, with experimental features enabled. `dockerfile:1.2.1`, with experimental features enabled.
@ -96,8 +97,8 @@ compatible. Pin the version to avoid having to deal with breaking changes.
## Other resources ## Other resources
For documentation on "labs" features, master builds, and nightly feature For documentation on `labs` features, master builds, and nightly feature
releases, refer to the description in [the BuildKit source repository on GitHub](https://github.com/moby/buildkit/blob/master/README.md). releases, refer to the description in [the BuildKit source repository on GitHub](https://github.com/moby/buildkit/blob/master/README.md).
For a full list of available images, visit the [`docker/dockerfile` repository on Docker Hub](https://hub.docker.com/r/docker/dockerfile), For a full list of available images, visit the [`docker/dockerfile` repository on Docker Hub](https://hub.docker.com/r/docker/dockerfile),
and the [`docker/dockerfile-upstream` repository on Docker Hub](https://hub.docker.com/r/docker/dockerfile-upstream) and the [`docker/dockerfile-upstream` repository on Docker Hub](https://hub.docker.com/r/docker/dockerfile-upstream)
for development builds. for development builds.

112
content/build/dockerfile/release-notes.md
View File

@ -16,22 +16,22 @@ For usage, see the [Dockerfile frontend syntax](frontend.md) page.
### New ### New
* Add `--start-interval` flag to the - Add `--start-interval` flag to the
[`HEALTHCHECK` instruction](../../engine/reference/builder.md#healthcheck). [`HEALTHCHECK` instruction](../../engine/reference/builder.md#healthcheck).
The following features have graduated from the labs channel to stable: The following features have graduated from the labs channel to stable:
* The `ADD` instruction can now [import files directly from Git URLs](../../engine/reference/builder.md#adding-a-git-repository-add-git-ref-dir) - The `ADD` instruction can now [import files directly from Git URLs](../../engine/reference/builder.md#adding-a-git-repository-add-git-ref-dir)
* The `ADD` instruction now supports [`--checksum` flag](../../engine/reference/builder.md#verifying-a-remote-file-checksum-add---checksumchecksum-http-src-dest) - The `ADD` instruction now supports [`--checksum` flag](../../engine/reference/builder.md#verifying-a-remote-file-checksum-add---checksumchecksum-http-src-dest)
to validate the contents of the remote URL contents to validate the contents of the remote URL contents
### Bug fixes and enhancements ### Bug fixes and enhancements
* Variable substitution now supports additional POSIX compatible variants without `:`. - Variable substitution now supports additional POSIX compatible variants without `:`.
[moby/buildkit#3611](https://github.com/moby/buildkit/pull/3611) [moby/buildkit#3611](https://github.com/moby/buildkit/pull/3611)
* Exported Windows images now contain OSVersion and OSFeatures values from base image. - Exported Windows images now contain OSVersion and OSFeatures values from base image.
[moby/buildkit#3619](https://github.com/moby/buildkit/pull/3619) [moby/buildkit#3619](https://github.com/moby/buildkit/pull/3619)
* Changed the permissions for Heredocs to 0644. - Changed the permissions for Heredocs to 0644.
[moby/buildkit#3992](https://github.com/moby/buildkit/pull/3992) [moby/buildkit#3992](https://github.com/moby/buildkit/pull/3992)
## 1.5.2 ## 1.5.2
@ -40,9 +40,9 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix building from Git reference that is missing branch name but contains a - Fix building from Git reference that is missing branch name but contains a
subdir subdir
* 386 platform image is now included in the release - 386 platform image is now included in the release
## 1.5.1 ## 1.5.1
@ -50,7 +50,7 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix possible panic when warning conditions appear in multi-platform builds - Fix possible panic when warning conditions appear in multi-platform builds
## 1.5.0 (labs) ## 1.5.0 (labs)
@ -60,7 +60,7 @@ The following features have graduated from the labs channel to stable:
### New ### New
* `ADD` command now supports [`--checksum` flag](../../engine/reference/builder.md#verifying-a-remote-file-checksum-add---checksumchecksum-http-src-dest) - `ADD` command now supports [`--checksum` flag](../../engine/reference/builder.md#verifying-a-remote-file-checksum-add---checksumchecksum-http-src-dest)
to validate the contents of the remote URL contents to validate the contents of the remote URL contents
## 1.5.0 ## 1.5.0
@ -69,20 +69,20 @@ The following features have graduated from the labs channel to stable:
### New ### New
* `ADD` command can now [import files directly from Git URLs](../../engine/reference/builder.md#adding-a-git-repository-add-git-ref-dir) - `ADD` command can now [import files directly from Git URLs](../../engine/reference/builder.md#adding-a-git-repository-add-git-ref-dir)
### Bug fixes and enhancements ### Bug fixes and enhancements
* Named contexts now support `oci-layout://` protocol for including images from - Named contexts now support `oci-layout://` protocol for including images from
local OCI layout structure local OCI layout structure
* Dockerfile now supports secondary requests for listing all build targets or - Dockerfile now supports secondary requests for listing all build targets or
printing outline of accepted parameters for a specific build target printing outline of accepted parameters for a specific build target
* Dockerfile `#syntax` directive that redirects to an external frontend image - Dockerfile `#syntax` directive that redirects to an external frontend image
now allows the directive to be also set with `//` comments or JSON. The file now allows the directive to be also set with `//` comments or JSON. The file
may also contain a shebang header may also contain a shebang header
* Named context can now be initialized with an empty scratch image - Named context can now be initialized with an empty scratch image
* Named contexts can now be initialized with an SSH Git URL - Named contexts can now be initialized with an SSH Git URL
* Fix handling of `ONBUILD` when importing Schema1 images - Fix handling of `ONBUILD` when importing Schema1 images
## 1.4.3 ## 1.4.3
@ -90,9 +90,9 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix creation timestamp not getting reset when building image from - Fix creation timestamp not getting reset when building image from
`docker-image://` named context `docker-image://` named context
* Fix passing `--platform` flag of `FROM` command when loading - Fix passing `--platform` flag of `FROM` command when loading
`docker-image://` named context `docker-image://` named context
## 1.4.2 ## 1.4.2
@ -101,7 +101,7 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix loading certain environment variables from an image passed with built - Fix loading certain environment variables from an image passed with built
context context
## 1.4.1 ## 1.4.1
@ -110,7 +110,7 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix named context resolution for cross-compilation cases from input when input - Fix named context resolution for cross-compilation cases from input when input
is built for a different platform is built for a different platform
## 1.4.0 ## 1.4.0
@ -119,24 +119,24 @@ The following features have graduated from the labs channel to stable:
### New ### New
* [`COPY --link` and `ADD --link`](../../engine/reference/builder.md#copy---link) - [`COPY --link` and `ADD --link`](../../engine/reference/builder.md#copy---link)
allow copying files with increased cache efficiency and rebase images without allow copying files with increased cache efficiency and rebase images without
requiring them to be rebuilt. `--link` copies files to a separate layer and requiring them to be rebuilt. `--link` copies files to a separate layer and
then uses new LLB MergeOp implementation to chain independent layers together then uses new LLB MergeOp implementation to chain independent layers together
* [Heredocs](../../engine/reference/builder.md#here-documents) support have - [Heredocs](../../engine/reference/builder.md#here-documents) support have
been promoted from labs channel to stable. This feature allows writing been promoted from labs channel to stable. This feature allows writing
multiline inline scripts and files multiline inline scripts and files
* Additional [named build contexts](../../engine/reference/commandline/buildx_build.md#build-context) - Additional [named build contexts](../../engine/reference/commandline/buildx_build.md#build-context)
can be passed to build to add or overwrite a stage or an image inside the can be passed to build to add or overwrite a stage or an image inside the
build. A source for the context can be a local source, image, Git, or HTTP URL build. A source for the context can be a local source, image, Git, or HTTP URL
* [`BUILDKIT_SANDBOX_HOSTNAME` build-arg](../../engine/reference/builder.md#buildkit-built-in-build-args) - [`BUILDKIT_SANDBOX_HOSTNAME` build-arg](../../engine/reference/builder.md#buildkit-built-in-build-args)
can be used to set the default hostname for the `RUN` steps can be used to set the default hostname for the `RUN` steps
### Bug fixes and enhancements ### Bug fixes and enhancements
* When using a cross-compilation stage, the target platform for a step is now - When using a cross-compilation stage, the target platform for a step is now
seen on progress output seen on progress output
* Fix some cases where Heredocs incorrectly removed quotes from content - Fix some cases where Heredocs incorrectly removed quotes from content
## 1.3.1 ## 1.3.1
@ -144,7 +144,7 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix parsing "required" mount key without a value - Fix parsing "required" mount key without a value
## 1.3.0 (labs) ## 1.3.0 (labs)
@ -154,7 +154,7 @@ The following features have graduated from the labs channel to stable:
### New ### New
* `RUN` and `COPY` commands now support [Here-document syntax](../../engine/reference/builder.md#here-documents) - `RUN` and `COPY` commands now support [Here-document syntax](../../engine/reference/builder.md#here-documents)
allowing writing multiline inline scripts and files allowing writing multiline inline scripts and files
## 1.3.0 ## 1.3.0
@ -163,17 +163,17 @@ The following features have graduated from the labs channel to stable:
### New ### New
* `RUN` command allows [`--network` flag](../../engine/reference/builder.md#run---network) - `RUN` command allows [`--network` flag](../../engine/reference/builder.md#run---network)
for requesting a specific type of network conditions. `--network=host` for requesting a specific type of network conditions. `--network=host`
requires allowing `network.host` entitlement. This feature was previously requires allowing `network.host` entitlement. This feature was previously
only available on labs channel only available on labs channel
### Bug fixes and enhancements ### Bug fixes and enhancements
* `ADD` command with a remote URL input now correctly handles the `--chmod` flag - `ADD` command with a remote URL input now correctly handles the `--chmod` flag
* Values for [`RUN --mount` flag](../../engine/reference/builder.md#run---mount) - Values for [`RUN --mount` flag](../../engine/reference/builder.md#run---mount)
now support variable expansion, except for the `from` field now support variable expansion, except for the `from` field
* Allow [`BUILDKIT_MULTI_PLATFORM` build arg](../../engine/reference/builder.md#buildkit-built-in-build-args) - Allow [`BUILDKIT_MULTI_PLATFORM` build arg](../../engine/reference/builder.md#buildkit-built-in-build-args)
to force always creating multi-platform image, even if only contains single to force always creating multi-platform image, even if only contains single
platform platform
@ -185,7 +185,7 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* `RUN` command allows [`--network` flag](../../engine/reference/builder.md#run---network) - `RUN` command allows [`--network` flag](../../engine/reference/builder.md#run---network)
for requesting a specific type of network conditions. `--network=host` for requesting a specific type of network conditions. `--network=host`
requires allowing `network.host` entitlement requires allowing `network.host` entitlement
@ -195,8 +195,8 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Revert "Ensure ENTRYPOINT command has at least one argument" - Revert "Ensure ENTRYPOINT command has at least one argument"
* Optimize processing `COPY` calls on multi-platform cross-compilation builds - Optimize processing `COPY` calls on multi-platform cross-compilation builds
## 1.2.0 (labs) ## 1.2.0 (labs)
@ -206,7 +206,7 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Experimental channel has been renamed to *labs* - Experimental channel has been renamed to _labs_
## 1.2.0 ## 1.2.0
@ -214,18 +214,18 @@ The following features have graduated from the labs channel to stable:
### New ### New
* [`RUN --mount` syntax](../../engine/reference/builder.md#run---mount) for - [`RUN --mount` syntax](../../engine/reference/builder.md#run---mount) for
creating secret, ssh, bind, and cache mounts have been moved to mainline creating secret, ssh, bind, and cache mounts have been moved to mainline
channel channel
* [`ARG` command](../../engine/reference/builder.md#arg) now supports defining - [`ARG` command](../../engine/reference/builder.md#arg) now supports defining
multiple build args on the same line similarly to `ENV` multiple build args on the same line similarly to `ENV`
### Bug fixes and enhancements ### Bug fixes and enhancements
* Metadata load errors are now handled as fatal to avoid incorrect build results - Metadata load errors are now handled as fatal to avoid incorrect build results
* Allow lowercase Dockerfile name - Allow lowercase Dockerfile name
* `--chown` flag in `ADD` now allows parameter expansion - `--chown` flag in `ADD` now allows parameter expansion
* `ENTRYPOINT` requires at least one argument to avoid creating broken images - `ENTRYPOINT` requires at least one argument to avoid creating broken images
## 1.1.7 ## 1.1.7
@ -233,7 +233,7 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Forward `FrontendInputs` to the gateway - Forward `FrontendInputs` to the gateway
## 1.1.2 (experimental) ## 1.1.2 (experimental)
@ -243,11 +243,11 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Allow setting security mode for a process with `RUN --security=sandbox|insecure` - Allow setting security mode for a process with `RUN --security=sandbox|insecure`
* Allow setting uid/gid for [cache mounts](../../engine/reference/builder.md#run---mounttypecache) - Allow setting uid/gid for [cache mounts](../../engine/reference/builder.md#run---mounttypecache)
* Avoid requesting internally linked paths to be pulled to build context - Avoid requesting internally linked paths to be pulled to build context
* Ensure missing cache IDs default to target paths - Ensure missing cache IDs default to target paths
* Allow setting namespace for cache mounts with [`BUILDKIT_CACHE_MOUNT_NS` build arg](../../engine/reference/builder.md#buildkit-built-in-build-args) - Allow setting namespace for cache mounts with [`BUILDKIT_CACHE_MOUNT_NS` build arg](../../engine/reference/builder.md#buildkit-built-in-build-args)
## 1.1.2 ## 1.1.2
@ -255,9 +255,9 @@ The following features have graduated from the labs channel to stable:
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix workdir creation with correct user and don't reset custom ownership - Fix workdir creation with correct user and don't reset custom ownership
* Fix handling empty build args also used as `ENV` - Fix handling empty build args also used as `ENV`
* Detect circular dependencies - Detect circular dependencies
## 1.1.0 ## 1.1.0
@ -265,14 +265,14 @@ The following features have graduated from the labs channel to stable:
### New ### New
* `ADD/COPY` commands now support implementation based on `llb.FileOp` and do - `ADD/COPY` commands now support implementation based on `llb.FileOp` and do
not require helper image if builtin file operations support is available not require helper image if builtin file operations support is available
* `--chown` flag for `COPY` command now supports variable expansion - `--chown` flag for `COPY` command now supports variable expansion
### Bug fixes and enhancements ### Bug fixes and enhancements
* To find the files ignored from the build context Dockerfile frontend will - To find the files ignored from the build context Dockerfile frontend will
first look for a file `<path/to/Dockerfile>.dockerignore` and if it is not first look for a file `<path/to/Dockerfile>.dockerignore` and if it is not
found `.dockerignore` file will be looked up from the root of the build found `.dockerignore` file will be looked up from the root of the build
context. This allows projects with multiple Dockerfiles to use different context. This allows projects with multiple Dockerfiles to use different
`.dockerignore` definitions `.dockerignore` definitions

16
content/build/drivers/_index.md
View File

@ -1,13 +1,14 @@
--- ---
title: Drivers overview title: Build drivers
description: Build drivers are configurations for how and where the BuildKit backend runs.
keywords: build, buildx, driver, builder, docker-container, kubernetes, remote keywords: build, buildx, driver, builder, docker-container, kubernetes, remote
aliases: aliases:
- /build/buildx/drivers/ - /build/buildx/drivers/
- /build/building/drivers/ - /build/building/drivers/
- /build/buildx/multiple-builders/ - /build/buildx/multiple-builders/
--- ---
Buildx drivers are configurations for how and where the BuildKit backend runs. Build drivers are configurations for how and where the BuildKit backend runs.
Driver settings are customizable and allows fine-grained control of the builder. Driver settings are customizable and allows fine-grained control of the builder.
Buildx supports the following drivers: Buildx supports the following drivers:
@ -33,10 +34,9 @@ The following table outlines some differences between drivers.
## What's next ## What's next
Read about each of the Buildx drivers to learn about how they work and how to Read about each driver:
use them:
- [Docker driver](./docker.md) - [Docker driver](./docker.md)
- [Docker container driver](./docker-container.md) - [Docker container driver](./docker-container.md)
- [Kubernetes driver](./kubernetes.md) - [Kubernetes driver](./kubernetes.md)
- [Remote driver](./remote.md) - [Remote driver](./remote.md)

15
content/build/drivers/docker-container.md
View File

@ -1,12 +1,13 @@
--- ---
title: Docker container driver title: Docker container build driver
description: The Docker container driver runs BuildKit in a container image.
keywords: build, buildx, driver, builder, docker-container keywords: build, buildx, driver, builder, docker-container
aliases: aliases:
- /build/buildx/drivers/docker-container/ - /build/buildx/drivers/docker-container/
- /build/building/drivers/docker-container/ - /build/building/drivers/docker-container/
--- ---
The buildx Docker container driver allows creation of a managed and customizable The Docker container driver allows creation of a managed and customizable
BuildKit environment in a dedicated Docker container. BuildKit environment in a dedicated Docker container.
Using the Docker container driver has a couple of advantages over the default Using the Docker container driver has a couple of advantages over the default
@ -33,7 +34,7 @@ The following table describes the available driver-specific options that you can
pass to `--driver-opt`: pass to `--driver-opt`:
| Parameter | Type | Default | Description | | Parameter | Type | Default | Description |
|-----------------|--------|------------------|--------------------------------------------------------------------------------------------| | --------------- | ------ | ---------------- | ------------------------------------------------------------------------------------------ |
| `image` | String | | Sets the image to use for running BuildKit. | | `image` | String | | Sets the image to use for running BuildKit. |
| `network` | String | | Sets the network mode for running the BuildKit container. | | `network` | String | | Sets the network mode for running the BuildKit container. |
| `cgroup-parent` | String | `/docker/buildx` | Sets the cgroup parent of the BuildKit container if Docker is using the `cgroupfs` driver. | | `cgroup-parent` | String | `/docker/buildx` | Sets the cgroup parent of the BuildKit container if Docker is using the `cgroupfs` driver. |
@ -171,14 +172,12 @@ $ docker buildx inspect --bootstrap
[Inspect the builder container](../../engine/reference/commandline/inspect.md) [Inspect the builder container](../../engine/reference/commandline/inspect.md)
and see what network is being used: and see what network is being used:
```console ```console
$ docker inspect buildx_buildkit_mybuilder0 --format={{.NetworkSettings.Networks}} $ docker inspect buildx_buildkit_mybuilder0 --format={{.NetworkSettings.Networks}}
map[foonet:0xc00018c0c0] map[foonet:0xc00018c0c0]
``` ```
## Further reading ## Further reading
For more information on the Docker container driver, see the For more information on the Docker container driver, see the
[buildx reference](../../engine/reference/commandline/buildx_create.md#driver). [buildx reference](../../engine/reference/commandline/buildx_create.md#driver).

9
content/build/drivers/docker.md
View File

@ -1,9 +1,12 @@
--- ---
title: Docker driver title: Docker driver
description: |
The Docker driver is the default driver.
It uses the BuildKit bundled with the Docker Engine.
keywords: build, buildx, driver, builder, docker keywords: build, buildx, driver, builder, docker
aliases: aliases:
- /build/buildx/drivers/docker/ - /build/buildx/drivers/docker/
- /build/building/drivers/docker/ - /build/building/drivers/docker/
--- ---
The Buildx Docker driver is the default driver. It uses the BuildKit server The Buildx Docker driver is the default driver. It uses the BuildKit server
@ -33,4 +36,4 @@ If you need additional configuration and flexibility, consider using the
## Further reading ## Further reading
For more information on the Docker driver, see the For more information on the Docker driver, see the
[buildx reference](../../engine/reference/commandline/buildx_create.md#driver). [buildx reference](../../engine/reference/commandline/buildx_create.md#driver).

51
content/build/drivers/kubernetes.md
View File

@ -1,14 +1,17 @@
--- ---
title: Kubernetes driver title: Kubernetes driver
description: |
The Kubernetes driver lets you run BuildKit in a Kubernetes cluster.
You can connect to, and run your builds in, the cluster using Buildx.
keywords: build, buildx, driver, builder, kubernetes keywords: build, buildx, driver, builder, kubernetes
aliases: aliases:
- /build/buildx/drivers/kubernetes/ - /build/buildx/drivers/kubernetes/
- /build/building/drivers/kubernetes/ - /build/building/drivers/kubernetes/
--- ---
The Buildx Kubernetes driver allows connecting your local development or CI The Kubernetes driver lets you connect your local development or CI
environments to your Kubernetes cluster to allow access to more powerful and environments to builders in a Kubernetes cluster to allow access to more
varied compute resources. powerful compute resources, optionally on multiple native architectures.
## Synopsis ## Synopsis
@ -23,8 +26,8 @@ $ docker buildx create \
--driver-opt=[key=value,...] --driver-opt=[key=value,...]
``` ```
The following table describes the available driver-specific options that you can The following table describes the available driver-specific options that you
pass to `--driver-opt`: can pass to `--driver-opt`:
| Parameter | Type | Default | Description | | Parameter | Type | Default | Description |
| ----------------- | ----------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | ----------------- | ----------------- | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
@ -98,7 +101,7 @@ replicas. `sticky` (the default) attempts to connect the same build performed
multiple times to the same node each time, ensuring better use of local cache. multiple times to the same node each time, ensuring better use of local cache.
For more information on scalability, see the options for For more information on scalability, see the options for
[buildx create](../../engine/reference/commandline/buildx_create.md#driver-opt). [`docker buildx create`](../../engine/reference/commandline/buildx_create.md#driver-opt).
## Node assignment ## Node assignment
@ -110,8 +113,8 @@ key-value pairs, where the key is the node label and the value is the label
text. For example: `"nodeselector=kubernetes.io/arch=arm64"` text. For example: `"nodeselector=kubernetes.io/arch=arm64"`
The `tolerations` parameter is a semicolon-separated list of taints. It accepts The `tolerations` parameter is a semicolon-separated list of taints. It accepts
the same values as the Kubernetes manifest. Each `tolerations` entry specifies a the same values as the Kubernetes manifest. Each `tolerations` entry specifies
taint key and the value, operator, or effect. For example: a taint key and the value, operator, or effect. For example:
`"tolerations=key=foo,value=bar;key=foo2,operator=exists;key=foo3,effect=NoSchedule"` `"tolerations=key=foo,value=bar;key=foo2,operator=exists;key=foo3,effect=NoSchedule"`
Due to quoting rules for shell commands, you must wrap the `nodeselector` and Due to quoting rules for shell commands, you must wrap the `nodeselector` and
@ -128,9 +131,9 @@ $ docker buildx create \
## Multi-platform builds ## Multi-platform builds
The Buildx Kubernetes driver has support for creating The Kubernetes driver has support for creating
[multi-platform images](../building/multi-platform.md), either using QEMU or by [multi-platform images](../building/multi-platform.md),
leveraging the native architecture of nodes. either using QEMU or by leveraging the native architecture of nodes.
### QEMU ### QEMU
@ -154,6 +157,7 @@ $ docker buildx build \
> QEMU performs full-system emulation of non-native platforms, which is much > QEMU performs full-system emulation of non-native platforms, which is much
> slower than native builds. Compute-heavy tasks like compilation and > slower than native builds. Compute-heavy tasks like compilation and
> compression/decompression will likely take a large performance hit. > compression/decompression will likely take a large performance hit.
{ .warning }
Using a custom BuildKit image or invoking non-native binaries in builds may Using a custom BuildKit image or invoking non-native binaries in builds may
require that you explicitly turn on QEMU using the `qemu.install` option when require that you explicitly turn on QEMU using the `qemu.install` option when
@ -208,7 +212,7 @@ $ docker buildx create \
--driver-opt=namespace=buildkit,nodeselector="kubernetes.io/arch=arm64" --driver-opt=namespace=buildkit,nodeselector="kubernetes.io/arch=arm64"
``` ```
If you list builders now, you should be able to see both nodes present: Listing your builders shows both nodes for the `kube` builder:
```console ```console
$ docker buildx ls $ docker buildx ls
@ -218,8 +222,8 @@ kube kubernetes
builder-arm64 kubernetes:///kube?deployment=builder-arm64&kubeconfig= running linux/arm64* builder-arm64 kubernetes:///kube?deployment=builder-arm64&kubeconfig= running linux/arm64*
``` ```
You should now be able to build multi-arch images with `amd64` and `arm64` You can now build multi-arch `amd64` and `arm64` images, by specifying those
combined, by specifying those platforms together in your buildx command: platforms together in your build command:
```console ```console
$ docker buildx build --builder=kube --platform=linux/amd64,linux/arm64 -t <user>/<image> --push . $ docker buildx build --builder=kube --platform=linux/amd64,linux/arm64 -t <user>/<image> --push .
@ -276,10 +280,9 @@ Prerequisites:
namespace/buildkit created namespace/buildkit created
``` ```
2. Create a new Buildx builder with the Kubernetes driver: 2. Create a new builder with the Kubernetes driver:
```console ```console
# Remember to specify the namespace in driver options
$ docker buildx create \ $ docker buildx create \
--bootstrap \ --bootstrap \
--name=kube \ --name=kube \
@ -287,7 +290,11 @@ Prerequisites:
--driver-opt=namespace=buildkit --driver-opt=namespace=buildkit
``` ```
3. List available Buildx builders using `docker buildx ls` > **Note**
>
> Remember to specify the namespace in driver options.
3. List available builders using `docker buildx ls`
```console ```console
$ docker buildx ls $ docker buildx ls
@ -298,7 +305,7 @@ Prerequisites:
default default running linux/amd64, linux/386 default default running linux/amd64, linux/386
``` ```
4. Inspect the running pods created by the Buildx driver with `kubectl`. 4. Inspect the running pods created by the build driver with `kubectl`.
```console ```console
$ kubectl -n buildkit get deployments $ kubectl -n buildkit get deployments
@ -310,7 +317,7 @@ Prerequisites:
kube0-6977cdcb75-k9h9m 1/1 Running 0 32s kube0-6977cdcb75-k9h9m 1/1 Running 0 32s
``` ```
The buildx driver creates the necessary resources on your cluster in the The build driver creates the necessary resources on your cluster in the
specified namespace (in this case, `buildkit`), while keeping your driver specified namespace (in this case, `buildkit`), while keeping your driver
configuration locally. configuration locally.
@ -331,4 +338,4 @@ That's it! You've now built an image from a Kubernetes pod, using Buildx!
## Further reading ## Further reading
For more information on the Kubernetes driver, see the For more information on the Kubernetes driver, see the
[buildx reference](../../engine/reference/commandline/buildx_create.md#driver). [buildx reference](../../engine/reference/commandline/buildx_create.md#driver).

46
content/build/drivers/remote.md
View File

@ -1,9 +1,12 @@
--- ---
title: Remote driver title: Remote driver
description: |
The remote driver lets you connect to a remote BuildKit instance
that you set up and configure manually.
keywords: build, buildx, driver, builder, remote keywords: build, buildx, driver, builder, remote
aliases: aliases:
- /build/buildx/drivers/remote/ - /build/buildx/drivers/remote/
- /build/building/drivers/remote/ - /build/building/drivers/remote/
--- ---
The Buildx remote driver allows for more complex custom build workloads, The Buildx remote driver allows for more complex custom build workloads,
@ -35,8 +38,7 @@ pass to `--driver-opt`:
This guide shows you how to create a setup with a BuildKit daemon listening on a This guide shows you how to create a setup with a BuildKit daemon listening on a
Unix socket, and have Buildx connect through it. Unix socket, and have Buildx connect through it.
1. Ensure that [BuildKit](https://github.com/moby/buildkit) 1. Ensure that [BuildKit](https://github.com/moby/buildkit) is installed.
is installed.
For example, you can launch an instance of buildkitd with: For example, you can launch an instance of buildkitd with:
@ -99,12 +101,12 @@ but this is for illustration purposes.)
You can use this [bake definition](https://github.com/moby/buildkit/blob/master/examples/create-certs) You can use this [bake definition](https://github.com/moby/buildkit/blob/master/examples/create-certs)
as a starting point: as a starting point:
```console ```console
SAN="localhost 127.0.0.1" docker buildx bake "https://github.com/moby/buildkit.git#master:examples/create-certs" SAN="localhost 127.0.0.1" docker buildx bake "https://github.com/moby/buildkit.git#master:examples/create-certs"
``` ```
Note that while it's possible to expose BuildKit over TCP without using Note that while it's possible to expose BuildKit over TCP without using
TLS, it's not recommended. Doing so allows arbitrary access to BuildKit TLS, it's not recommended. Doing so allows arbitrary access to BuildKit
without credentials. without credentials.
@ -174,22 +176,16 @@ copied between them.
tcp://buildkitd.default.svc:1234 tcp://buildkitd.default.svc:1234
``` ```
Note that this will only work internally, within the cluster, since the BuildKit Note that this only works internally, within the cluster, since the BuildKit
setup guide only creates a ClusterIP service. To configure the builder to be setup guide only creates a `ClusterIP` service. To access a builder remotely,
accessible remotely, you can use an appropriately configured ingress, which is you can set up and use an ingress, which is outside the scope of this guide.
outside the scope of this guide.
To access the service remotely, use the port forwarding mechanism of `kubectl`: ### Debug a remote builder in Kubernetes
```console If you're having trouble accessing a remote builder deployed in Kubernetes, you
$ kubectl port-forward svc/buildkitd 1234:1234 can use the `kube-pod://` URL scheme to connect directly to a BuildKit pod
``` through the Kubernetes API. Note that this method only connects to a single pod
in the deployment.
Then you can point the remote driver at `tcp://localhost:1234`.
Alternatively, you can use the `kube-pod://` URL scheme to connect directly to a
BuildKit pod through the Kubernetes API. Note that this method only connects to
a single pod in the deployment:
```console ```console
$ kubectl get pods --selector=app=buildkitd -o json | jq -r '.items[].metadata.name $ kubectl get pods --selector=app=buildkitd -o json | jq -r '.items[].metadata.name
@ -198,4 +194,12 @@ $ docker buildx create \
--name remote-container \ --name remote-container \
--driver remote \ --driver remote \
kube-pod://buildkitd-XXXXXXXXXX-xxxxx kube-pod://buildkitd-XXXXXXXXXX-xxxxx
``` ```
Alternatively, use the port forwarding mechanism of `kubectl`:
```console
$ kubectl port-forward svc/buildkitd 1234:1234
```
Then you can point the remote driver at `tcp://localhost:1234`.

26
content/build/exporters/_index.md
View File

@ -1,11 +1,9 @@
--- ---
title: Exporters overview title: Exporters overview
keywords: 'build, buildx, buildkit, exporter, image, registry, local, tar, oci, docker, description: Build exporters define the output format of your build result
cacheonly keywords: build, buildx, buildkit, exporter, image, registry, local, tar, oci, docker, cacheonly
'
aliases: aliases:
- /build/building/exporters/ - /build/building/exporters/
--- ---
Exporters save your build results to a specified output type. You specify the Exporters save your build results to a specified output type. You specify the
@ -36,10 +34,10 @@ $ docker buildx build --tag <registry>/<image> \
--output type=<TYPE> . --output type=<TYPE> .
``` ```
Most common use cases doesn't require you don't need to specify which exporter Most common use cases don't require that you specify which exporter to use
to use explicitly. You only need to specify the exporter if you intend to explicitly. You only need to specify the exporter if you intend to customize
customize the output somehow, or if you want to save it to disk. The `--load` the output, or if you want to save it to disk. The `--load` and `--push`
and `--push` options allow Buildx to infer the exporter settings to use. options allow Buildx to infer the exporter settings to use.
For example, if you use the `--push` option in combination with `--tag`, Buildx For example, if you use the `--push` option in combination with `--tag`, Buildx
automatically uses the `image` exporter, and configures the exporter to push the automatically uses the `image` exporter, and configures the exporter to push the
@ -152,7 +150,7 @@ $ docker buildx build --output type=tar,dest=<path/to/output> .
``` ```
The `local` exporter is useful in [multi-stage builds](../building/multi-stage.md) The `local` exporter is useful in [multi-stage builds](../building/multi-stage.md)
since it allows you to export only a minimal number of build artifacts. For example, since it allows you to export only a minimal number of build artifacts, such as
self-contained binaries. self-contained binaries.
### Cache-only export ### Cache-only export
@ -248,12 +246,10 @@ the previous compression algorithm.
### OCI media types ### OCI media types
Exporters that output container images, support creating images with either The `image`, `registry`, `oci` and `docker` exporters create container images.
Docker media types (the default) or with OCI media types. This is supported by These exporters support both Docker media types (default) and OCI media types
the `image`, `registry`, `oci` and `docker` exporters.
To export images with OCI media types set, use the `oci-mediatypes` property. To export images with OCI media types set, use the `oci-mediatypes` property.
For example, with the `image` exporter:
```console ```console
$ docker buildx build \ $ docker buildx build \
@ -267,4 +263,4 @@ them:
- [Image and registry exporters](image-registry.md) - [Image and registry exporters](image-registry.md)
- [OCI and Docker exporters](oci-docker.md). - [OCI and Docker exporters](oci-docker.md).
- [Local and tar exporters](local-tar.md) - [Local and tar exporters](local-tar.md)

26
content/build/exporters/image-registry.md
View File

@ -1,10 +1,11 @@
--- ---
title: Image and registry exporters title: Image and registry exporters
keywords: 'build, buildx, buildkit, exporter, image, registry description: |
The image and registry exporters create an image that can be loaded to your
' local image store or pushed to a registry
keywords: build, buildx, buildkit, exporter, image, registry
aliases: aliases:
- /build/building/exporters/image-registry/ - /build/building/exporters/image-registry/
--- ---
The `image` exporter outputs the build result into a container image format. The The `image` exporter outputs the build result into a container image format. The
@ -17,9 +18,6 @@ Build a container image using the `image` and `registry` exporters:
```console ```console
$ docker buildx build --output type=image[,parameters] . $ docker buildx build --output type=image[,parameters] .
```
```console
$ docker buildx build --output type=registry[,parameters] . $ docker buildx build --output type=registry[,parameters] .
``` ```
@ -27,7 +25,7 @@ The following table describes the available parameters that you can pass to
`--output` for `type=image`: `--output` for `type=image`:
| Parameter | Type | Default | Description | | Parameter | Type | Default | Description |
|------------------------|----------------------------------------|---------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | ---------------------- | -------------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | String | | Specify image name(s) | | `name` | String | | Specify image name(s) |
| `push` | `true`,`false` | `false` | Push after creating the image. | | `push` | `true`,`false` | `false` | Push after creating the image. |
| `push-by-digest` | `true`,`false` | `false` | Push image without name. | | `push-by-digest` | `true`,`false` | `false` | Push image without name. |
@ -42,15 +40,15 @@ The following table describes the available parameters that you can pass to
| `store` | `true`,`false` | `true` | Store the result images to the worker's (for example, containerd) image store, and ensures that the image has all blobs in the content store. Ignored if the worker doesn't have image store (when using OCI workers, for example). | | `store` | `true`,`false` | `true` | Store the result images to the worker's (for example, containerd) image store, and ensures that the image has all blobs in the content store. Ignored if the worker doesn't have image store (when using OCI workers, for example). |
| `annotation.<key>` | String | | Attach an annotation with the respective `key` and `value` to the built image,see [annotations][3] | | `annotation.<key>` | String | | Attach an annotation with the respective `key` and `value` to the built image,see [annotations][3] |
[1]: index.md#compression [1]: _index.md#compression
[2]: index.md#oci-media-types [2]: _index.md#oci-media-types
[3]: #annotations [3]: #annotations
## Annotations ## Annotations
These exporters support adding OCI annotation using `annotation.*` dot notation These exporters support adding OCI annotation using `annotation` parameter,
parameter. The following example sets the `org.opencontainers.image.title` followed by the annotation name using dot notation. The following example sets
annotation for a build: the `org.opencontainers.image.title` annotation:
```console ```console
$ docker buildx build \ $ docker buildx build \
@ -63,4 +61,4 @@ For more information about annotations, see
## Further reading ## Further reading
For more information on the `image` or `registry` exporters, see the For more information on the `image` or `registry` exporters, see the
[BuildKit README](https://github.com/moby/buildkit/blob/master/README.md#imageregistry). [BuildKit README](https://github.com/moby/buildkit/blob/master/README.md#imageregistry).

15
content/build/exporters/local-tar.md
View File

@ -1,10 +1,10 @@
--- ---
title: Local and tar exporters title: Local and tar exporters
keywords: 'build, buildx, buildkit, exporter, local, tar keywords: build, buildx, buildkit, exporter, local, tar
description: >
' The local and tar exporters save the build result to the local filesystem
aliases: aliases:
- /build/building/exporters/local-tar/ - /build/building/exporters/local-tar/
--- ---
The `local` and `tar` exporters output the root filesystem of the build result The `local` and `tar` exporters output the root filesystem of the build result
@ -20,19 +20,16 @@ Build a container image using the `local` exporter:
```console ```console
$ docker buildx build --output type=local[,parameters] . $ docker buildx build --output type=local[,parameters] .
```
```console
$ docker buildx build --output type=tar[,parameters] . $ docker buildx build --output type=tar[,parameters] .
``` ```
The following table describes the available parameters: The following table describes the available parameters:
| Parameter | Type | Default | Description | | Parameter | Type | Default | Description |
|-----------|--------|---------|-----------------------| | --------- | ------ | ------- | --------------------- |
| `dest` | String | | Path to copy files to | | `dest` | String | | Path to copy files to |
## Further reading ## Further reading
For more information on the `local` or `tar` exporters, see the For more information on the `local` or `tar` exporters, see the
[BuildKit README](https://github.com/moby/buildkit/blob/master/README.md#local-directory). [BuildKit README](https://github.com/moby/buildkit/blob/master/README.md#local-directory).

22
content/build/exporters/oci-docker.md
View File

@ -1,10 +1,10 @@
--- ---
title: OCI and Docker exporters title: OCI and Docker exporters
keywords: 'build, buildx, buildkit, exporter, oci, docker keywords: build, buildx, buildkit, exporter, oci, docker
description: >
' The OCI and Docker exporters create an image layout tarball on the local filesystem
aliases: aliases:
- /build/building/exporters/local-tar/ - /build/building/exporters/local-tar/
--- ---
The `oci` exporter outputs the build result into an The `oci` exporter outputs the build result into an
@ -31,7 +31,7 @@ $ docker buildx build --output type=docker[,parameters] .
The following table describes the available parameters: The following table describes the available parameters:
| Parameter | Type | Default | Description | | Parameter | Type | Default | Description |
|---------------------|----------------------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------| | ------------------- | -------------------------------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `name` | String | | Specify image name(s) | | `name` | String | | Specify image name(s) |
| `dest` | String | | Path | | `dest` | String | | Path |
| `tar` | `true`,`false` | `true` | Bundle the output into a tarball layout | | `tar` | `true`,`false` | `true` | Bundle the output into a tarball layout |
@ -41,15 +41,15 @@ The following table describes the available parameters:
| `oci-mediatypes` | `true`,`false` | | Use OCI media types in exporter manifests. Defaults to `true` for `type=oci`, and `false` for `type=docker`. See [OCI Media types][2] | | `oci-mediatypes` | `true`,`false` | | Use OCI media types in exporter manifests. Defaults to `true` for `type=oci`, and `false` for `type=docker`. See [OCI Media types][2] |
| `annotation.<key>` | String | | Attach an annotation with the respective `key` and `value` to the built image,see [annotations][3] | | `annotation.<key>` | String | | Attach an annotation with the respective `key` and `value` to the built image,see [annotations][3] |
[1]: index.md#compression [1]: _index.md#compression
[2]: index.md#oci-media-types [2]: _index.md#oci-media-types
[3]: #annotations [3]: #annotations
## Annotations ## Annotations
These exporters support adding OCI annotation using `annotation.*` dot notation These exporters support adding OCI annotation using `annotation` parameter,
parameter. The following example sets the `org.opencontainers.image.title` followed by the annotation name using dot notation. The following example sets
annotation for a build: the `org.opencontainers.image.title` annotation:
```console ```console
$ docker buildx build \ $ docker buildx build \
@ -62,4 +62,4 @@ For more information about annotations, see
## Further reading ## Further reading
For more information on the `oci` or `docker` exporters, see the For more information on the `oci` or `docker` exporters, see the
[BuildKit README](https://github.com/moby/buildkit/blob/master/README.md#docker-tarball). [BuildKit README](https://github.com/moby/buildkit/blob/master/README.md#docker-tarball).

653
content/build/release-notes.md
View File

@ -127,9 +127,9 @@ The full release note for this release is available
### Bug fixes and enhancements ### Bug fixes and enhancements
* Add `BUILDX_NO_DEFAULT_ATTESTATIONS` as alternative to `--provenance false`. {% include github_issue.md repo="docker/buildx" number="1645" %} - Add `BUILDX_NO_DEFAULT_ATTESTATIONS` as alternative to `--provenance false`. [docker/buildx#1645](https://github.com/docker/buildx/issues/1645)
* Disable dirty Git checkout detection by default for performance. Can be enabled with `BUILDX_GIT_CHECK_DIRTY` opt-in. {% include github_issue.md repo="docker/buildx" number="1650" %} - Disable dirty Git checkout detection by default for performance. Can be enabled with `BUILDX_GIT_CHECK_DIRTY` opt-in. [docker/buildx#1650](https://github.com/docker/buildx/issues/1650)
* Strip credentials from VCS hint URL before sending to BuildKit. {% include github_issue.md repo="docker/buildx" number="1664" %} - Strip credentials from VCS hint URL before sending to BuildKit. [docker/buildx#1664](https://github.com/docker/buildx/issues/1664)
## 0.10.3 ## 0.10.3
@ -139,11 +139,11 @@ The full release note for this release is available
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix reachable commit and warnings on collecting Git provenance info. {% include github_issue.md repo="docker/buildx" number="1592" %} {% include github_issue.md repo="docker/buildx" number="1634" %} - Fix reachable commit and warnings on collecting Git provenance info. [docker/buildx#1592](https://github.com/docker/buildx/issues/1592), [docker/buildx#1634](https://github.com/docker/buildx/issues/1634)
* Fix a regression where docker context was not being validated. {% include github_issue.md repo="docker/buildx" number="1596" %} - Fix a regression where docker context was not being validated. [docker/buildx#1596](https://github.com/docker/buildx/issues/1596)
* Fix function resolution with JSON bake definition. {% include github_issue.md repo="docker/buildx" number="1605" %} - Fix function resolution with JSON bake definition. [docker/buildx#1605](https://github.com/docker/buildx/issues/1605)
* Fix case where original HCL bake diagnostic is discarded. {% include github_issue.md repo="docker/buildx" number="1607" %} - Fix case where original HCL bake diagnostic is discarded. [docker/buildx#1607](https://github.com/docker/buildx/issues/1607)
* Fix labels not correctly set with bake and compose file. {% include github_issue.md repo="docker/buildx" number="1631" %} - Fix labels not correctly set with bake and compose file. [docker/buildx#1631](https://github.com/docker/buildx/issues/1631)
## 0.10.2 ## 0.10.2
@ -153,11 +153,11 @@ The full release note for this release is available
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix preferred platforms order not taken into account in multi-node builds. {% include github_issue.md repo="docker/buildx" number="1561" %} - Fix preferred platforms order not taken into account in multi-node builds. [docker/buildx#1561](https://github.com/docker/buildx/issues/1561)
* Fix possible panic on handling `SOURCE_DATE_EPOCH` environment variable. {% include github_issue.md repo="docker/buildx" number="1564" %} - Fix possible panic on handling `SOURCE_DATE_EPOCH` environment variable. [docker/buildx#1564](https://github.com/docker/buildx/issues/1564)
* Fix possible push error on multi-node manifest merge since BuildKit v0.11 on - Fix possible push error on multi-node manifest merge since BuildKit v0.11 on
some registries. {% include github_issue.md repo="docker/buildx" number="1566" %} some registries. [docker/buildx#1566](https://github.com/docker/buildx/issues/1566)
* Improve warnings on collecting Git provenance info. {% include github_issue.md repo="docker/buildx" number="1568" %} - Improve warnings on collecting Git provenance info. [docker/buildx#1568](https://github.com/docker/buildx/issues/1568)
## 0.10.1 ## 0.10.1
@ -167,14 +167,14 @@ The full release note for this release is available
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix sending the correct origin URL as `vsc:source` metadata. {% include github_issue.md repo="docker/buildx" number="1548" %} - Fix sending the correct origin URL as `vsc:source` metadata. [docker/buildx#1548](https://github.com/docker/buildx/issues/1548)
* Fix possible panic from data-race. {% include github_issue.md repo="docker/buildx" number="1504" %} - Fix possible panic from data-race. [docker/buildx#1504](https://github.com/docker/buildx/issues/1504)
* Fix regression with `rm --all-inactive`. {% include github_issue.md repo="docker/buildx" number="1547" %} - Fix regression with `rm --all-inactive`. [docker/buildx#1547](https://github.com/docker/buildx/issues/1547)
* Improve attestation access in `imagetools inspect` by lazily loading data. {% include github_issue.md repo="docker/buildx" number="1546" %} - Improve attestation access in `imagetools inspect` by lazily loading data. [docker/buildx#1546](https://github.com/docker/buildx/issues/1546)
* Correctly mark capabilities request as internal. {% include github_issue.md repo="docker/buildx" number="1538" %} - Correctly mark capabilities request as internal. [docker/buildx#1538](https://github.com/docker/buildx/issues/1538)
* Detect invalid attestation configuration. {% include github_issue.md repo="docker/buildx" number="1545" %} - Detect invalid attestation configuration. [docker/buildx#1545](https://github.com/docker/buildx/issues/1545)
* Update containerd patches to fix possible push regression affecting - Update containerd patches to fix possible push regression affecting
`imagetools` commands. {% include github_issue.md repo="docker/buildx" number="1559" %} `imagetools` commands. [docker/buildx#1559](https://github.com/docker/buildx/issues/1559)
## 0.10.0 ## 0.10.0
@ -184,183 +184,197 @@ The full release note for this release is available
### New ### New
* The `buildx build` command supports new `--attest` flag, along with - The `buildx build` command supports new `--attest` flag, along with
shorthands `--sbom` and `--provenance`, for adding attestations for your shorthands `--sbom` and `--provenance`, for adding attestations for your
current build. {% include github_issue.md repo="docker/buildx" number="1412" %} current build. [docker/buildx#1412](https://github.com/docker/buildx/issues/1412)
{% include github_issue.md repo="docker/buildx" number="1475" %} [docker/buildx#1475](https://github.com/docker/buildx/issues/1475)
* `--attest type=sbom` or `--sbom=true` adds [SBOM attestations](attestations/sbom.md). - `--attest type=sbom` or `--sbom=true` adds [SBOM attestations](attestations/sbom.md).
* `--attest type=provenance` or `--provenance=true` adds [SLSA provenance attestation](attestations/slsa-provenance.md) - `--attest type=provenance` or `--provenance=true` adds [SLSA provenance attestation](attestations/slsa-provenance.md).
* When creating OCI images, a minimal provenance attestation is included - When creating OCI images, a minimal provenance attestation is included
with the image by default. with the image by default.
* When building with BuildKit that supports provenance attestations Buildx will - When building with BuildKit that supports provenance attestations Buildx will
automatically share the version control information of your build context, so automatically share the version control information of your build context, so
it can be shown in provenance for later debugging. Previously this only it can be shown in provenance for later debugging. Previously this only
happened when building from a Git URL directly. To opt-out of this behavior happened when building from a Git URL directly. To opt-out of this behavior
you can set `BUILDX_GIT_INFO=0`. Optionally you can also automatically define you can set `BUILDX_GIT_INFO=0`. Optionally you can also automatically define
labels with VCS info by setting `BUILDX_GIT_LABELS=1`. {% include github_issue.md repo="docker/buildx" number="1462" %} labels with VCS info by setting `BUILDX_GIT_LABELS=1`.
{% include github_issue.md repo="docker/buildx" number="1297" %} {% include github_issue.md repo="docker/buildx" number="1341" %} [docker/buildx#1462](https://github.com/docker/buildx/issues/1462),
{% include github_issue.md repo="docker/buildx" number="1468" %} {% include github_issue.md repo="docker/buildx" number="1477" %} [docker/buildx#1297](https://github.com/docker/buildx),
* Named contexts with `--build-context` now support `oci-layout://` protocol [docker/buildx#1341](https://github.com/docker/buildx/issues/1341),
[docker/buildx#1468](https://github.com/docker/buildx),
[docker/buildx#1477](https://github.com/docker/buildx/issues/1477)
- Named contexts with `--build-context` now support `oci-layout://` protocol
for initializing the context with a value of a local OCI layout directory. for initializing the context with a value of a local OCI layout directory.
E.g. `--build-context stagename=oci-layout://path/to/dir`. This feature E.g. `--build-context stagename=oci-layout://path/to/dir`. This feature
requires BuildKit v0.11.0+ and Dockerfile 1.5.0+. {% include github_issue.md repo="docker/buildx" number="1456" %} requires BuildKit v0.11.0+ and Dockerfile 1.5.0+. [docker/buildx#1456](https://github.com/docker/buildx/issues/1456)
* Bake now supports [resource interpolation](bake/configuring-build.md#resource-interpolation) - Bake now supports [resource interpolation](bake/configuring-build.md#resource-interpolation)
where you can reuse the values from other target definitions. {% include github_issue.md repo="docker/buildx" number="1434" %} where you can reuse the values from other target definitions. [docker/buildx#1434](https://github.com/docker/buildx/issues/1434)
* Buildx will now automatically forward `SOURCE_DATE_EPOCH` environment variable - Buildx will now automatically forward `SOURCE_DATE_EPOCH` environment variable
if it is defined in your environment. This feature is meant to be used with if it is defined in your environment. This feature is meant to be used with
updated [reproducible builds](https://github.com/moby/buildkit/blob/master/docs/build-repro.md) updated [reproducible builds](https://github.com/moby/buildkit/blob/master/docs/build-repro.md)
support in BuildKit v0.11.0+. {% include github_issue.md repo="docker/buildx" number="1482" %} support in BuildKit v0.11.0+. [docker/buildx#1482](https://github.com/docker/buildx/issues/1482)
* Buildx now remembers the last activity for a builder for better organization - Buildx now remembers the last activity for a builder for better organization
of builder instances. {% include github_issue.md repo="docker/buildx" number="1439" %} of builder instances. [docker/buildx#1439](https://github.com/docker/buildx/issues/1439)
* Bake definition now supports null values for [variables](bake/reference.md#variable) and [labels](bake/reference.md#targetlabels) - Bake definition now supports null values for [variables](bake/reference.md#variable) and [labels](bake/reference.md#targetlabels)
for build arguments and labels to use the defaults set in the Dockerfile {% include github_issue.md repo="docker/buildx" number="1449" %} for build arguments and labels to use the defaults set in the Dockerfile.
* The [`buildx imagetools inspect` command](../engine/reference/commandline/buildx_imagetools_inspect.md) [docker/buildx#1449](https://github.com/docker/buildx/issues/1449)
now supports showing SBOM and Provenance data {% include github_issue.md repo="docker/buildx" number="1444" %} - The [`buildx imagetools inspect` command](../engine/reference/commandline/buildx_imagetools_inspect.md)
{% include github_issue.md repo="docker/buildx" number="1498" %} now supports showing SBOM and Provenance data.
* Increase performance of `ls` command and inspect flows {% include github_issue.md repo="docker/buildx" number="1430" %} [docker/buildx#1444](https://github.com/docker/buildx/issues/1444),
{% include github_issue.md repo="docker/buildx" number="1454" %} {% include github_issue.md repo="docker/buildx" number="1455" %} [docker/buildx#1498](https://github.com/docker/buildx/issues/1498)
{% include github_issue.md repo="docker/buildx" number="1345" %} - Increase performance of `ls` command and inspect flows.
* Adding extra hosts with [Docker driver](drivers/docker.md) now supports [docker/buildx#1430](https://github.com/docker/buildx/issues/1430),
Docker-specific `host-gateway` special value {% include github_issue.md repo="docker/buildx" number="1446" %} [docker/buildx#1454](https://github.com/docker/buildx/issues/1454),
* [OCI exporter](exporters/oci-docker.md) now supports `tar=false` option for [docker/buildx#1455](https://github.com/docker/buildx/issues/1455),
exporting OCI format directly in a directory {% include github_issue.md repo="docker/buildx" number="1420" %} [docker/buildx#1345](https://github.com/docker/buildx/issues/1345)
- Adding extra hosts with [Docker driver](drivers/docker.md) now supports
Docker-specific `host-gateway` special value. [docker/buildx#1446](https://github.com/docker/buildx/issues/1446)
- [OCI exporter](exporters/oci-docker.md) now supports `tar=false` option for
exporting OCI format directly in a directory. [docker/buildx#1420](https://github.com/docker/buildx/issues/1420)
### Upgrades ### Upgrades
* Updated the Compose Specification to 1.6.0 {% include github_issue.md repo="docker/buildx" number="1387" %} - Updated the Compose Specification to 1.6.0. [docker/buildx#1387](https://github.com/docker/buildx/issues/1387)
### Bug fixes and enhancements ### Bug fixes and enhancements
* `--invoke` can now load default launch environment from the image metadata {% include github_issue.md repo="docker/buildx" number="1324" %} - `--invoke` can now load default launch environment from the image metadata. [docker/buildx#1324](https://github.com/docker/buildx/issues/1324)
* Fix container driver behavior in regards to UserNS {% include github_issue.md repo="docker/buildx" number="1368" %} - Fix container driver behavior in regards to UserNS. [docker/buildx#1368](https://github.com/docker/buildx/issues/1368)
* Fix possible panic in Bake when using wrong variable value type {% include github_issue.md repo="docker/buildx" number="1442" %} - Fix possible panic in Bake when using wrong variable value type. [docker/buildx#1442](https://github.com/docker/buildx/issues/1442)
* Fix possible panic in `imagetools inspect` {% include github_issue.md repo="docker/buildx" number="1441" %} - Fix possible panic in `imagetools inspect`. [docker/buildx#1441](https://github.com/docker/buildx/issues/1441)
{% include github_issue.md repo="docker/buildx" number="1406" %} [docker/buildx#1406](https://github.com/docker/buildx/issues/1406)
* Fix sending empty `--add-host` value to BuildKit by default {% include github_issue.md repo="docker/buildx" number="1457" %} - Fix sending empty `--add-host` value to BuildKit by default. [docker/buildx#1457](https://github.com/docker/buildx/issues/1457)
* Fix handling progress prefixes with progress groups {% include github_issue.md repo="docker/buildx" number="1305" %} - Fix handling progress prefixes with progress groups. [docker/buildx#1305](https://github.com/docker/buildx/issues/1305)
* Fix recursively resolving groups in Bake {% include github_issue.md repo="docker/buildx" number="1313" %} - Fix recursively resolving groups in Bake. [docker/buildx#1313](https://github.com/docker/buildx/issues/1313)
* Fix possible wrong indentation on multi-node builder manifests {% include github_issue.md repo="docker/buildx" number="1396" %} - Fix possible wrong indentation on multi-node builder manifests. [docker/buildx#1396](https://github.com/docker/buildx/issues/1396)
* Fix possible panic from missing OpenTelemetry configuration {% include github_issue.md repo="docker/buildx" number="1383" %} - Fix possible panic from missing OpenTelemetry configuration. [docker/buildx#1383](https://github.com/docker/buildx/issues/1383)
* Fix `--progress=tty` behavior when TTY is not available {% include github_issue.md repo="docker/buildx" number="1371" %} - Fix `--progress=tty` behavior when TTY is not available. [docker/buildx#1371](https://github.com/docker/buildx/issues/1371)
* Fix connection error conditions in `prune` and `du` commands {% include github_issue.md repo="docker/buildx" number="1307" %} - Fix connection error conditions in `prune` and `du` commands. [docker/buildx#1307](https://github.com/docker/buildx/issues/1307)
## 0.9.1 ## 0.9.1
{{< release-date date="2022-08-18" >}} {{< release-date date="2022-08-18" >}}
### Bug fixes and enhancements ### Bug fixes and enhancements
* The `inspect` command now displays the BuildKit version in use {% include github_issue.md repo="docker/buildx" number="1279" %} - The `inspect` command now displays the BuildKit version in use. [docker/buildx#1279](https://github.com/docker/buildx/issues/1279)
* Fixed a regression when building Compose files that contain services without a - Fixed a regression when building Compose files that contain services without a
build block {% include github_issue.md repo="docker/buildx" number="1277" %} build block. [docker/buildx#1277](https://github.com/docker/buildx/issues/1277)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.9.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.9.1).
## 0.9.0 ## 0.9.0
{{< release-date date="2022-08-17" >}} {{< release-date date="2022-08-17" >}}
### New ### New
* Support for new [driver `remote`](drivers/remote.md) that you can use - Support for a new [`remote` driver](drivers/remote.md) that you can use
to connect to any already running BuildKit instance {% include github_issue.md repo="docker/buildx" number="1078" %} to connect to any already running BuildKit instance.
{% include github_issue.md repo="docker/buildx" number="1093" %} {% include github_issue.md repo="docker/buildx" number="1094" %} [docker/buildx#1078](https://github.com/docker/buildx/issues/1078),
{% include github_issue.md repo="docker/buildx" number="1103" %} {% include github_issue.md repo="docker/buildx" number="1134" %} [docker/buildx#1093](https://github.com/docker/buildx/issues/1093),
{% include github_issue.md repo="docker/buildx" number="1204" %} [docker/buildx#1094](https://github.com/docker/buildx/issues/1094),
* You can now load Dockerfile from standard input even when the build context is [docker/buildx#1103](https://github.com/docker/buildx/issues/1103),
coming from external Git or HTTP URL {% include github_issue.md repo="docker/buildx" number="994" %} [docker/buildx#1134](https://github.com/docker/buildx/issues/1134),
* Build commands now support new the build context type `oci-layout://` for loading [docker/buildx#1204](https://github.com/docker/buildx/issues/1204)
- You can now load Dockerfile from standard input even when the build context is
coming from external Git or HTTP URL. [docker/buildx#994](https://github.com/docker/buildx/issues/994)
- Build commands now support new the build context type `oci-layout://` for loading
[build context from local OCI layout directories](../engine/reference/commandline/buildx_build.md#source-oci-layout). [build context from local OCI layout directories](../engine/reference/commandline/buildx_build.md#source-oci-layout).
Note that this feature depends on an unreleased BuildKit feature and builder Note that this feature depends on an unreleased BuildKit feature and builder
instance from `moby/buildkit:master` needs to be used until BuildKit v0.11 is instance from `moby/buildkit:master` needs to be used until BuildKit v0.11 is
released {% include github_issue.md repo="docker/buildx" number="1173" %} released. [docker/buildx#1173](https://github.com/docker/buildx/issues/1173)
* You can now use the new `--print` flag to run helper functions supported by the - You can now use the new `--print` flag to run helper functions supported by the
BuildKit frontend performing the build and print their results. You can use BuildKit frontend performing the build and print their results. You can use
this feature in Dockerfile to show the build arguments and secrets that the this feature in Dockerfile to show the build arguments and secrets that the
current build supports with `--print=outline` and list all available current build supports with `--print=outline` and list all available
Dockerfile stages with `--print=targets`. This feature is experimental for Dockerfile stages with `--print=targets`. This feature is experimental for
gathering early feedback and requires enabling `BUILDX_EXPERIMENTAL=1` gathering early feedback and requires enabling `BUILDX_EXPERIMENTAL=1`
environment variable. We plan to update/extend this feature in the future environment variable. We plan to update/extend this feature in the future
without keeping backward compatibility {% include github_issue.md repo="docker/buildx" number="1100" %} without keeping backward compatibility. [docker/buildx#1100](https://github.com/docker/buildx/issues/1100),
{% include github_issue.md repo="docker/buildx" number="1272" %} [docker/buildx#1272](https://github.com/docker/buildx/issues/1272)
* You can now use the new `--invoke` flag to launch interactive containers from - You can now use the new `--invoke` flag to launch interactive containers from
build results for an interactive debugging cycle. You can reload these build results for an interactive debugging cycle. You can reload these
containers with code changes or restore them to an initial state from the containers with code changes or restore them to an initial state from the
special monitor mode. This feature is experimental for gathering early special monitor mode. This feature is experimental for gathering early
feedback and requires enabling `BUILDX_EXPERIMENTAL=1` environment variable. feedback and requires enabling `BUILDX_EXPERIMENTAL=1` environment variable.
We plan to update/extend this feature in the future without enabling backward We plan to update/extend this feature in the future without enabling backward
compatibility {% include github_issue.md repo="docker/buildx" number="1168" %} compatibility.
{% include github_issue.md repo="docker/buildx" number="1257" %} {% include github_issue.md repo="docker/buildx" number="1259" %} [docker/buildx#1168](https://github.com/docker/buildx/issues/1168),
* Buildx now understands environment variable `BUILDKIT_COLORS` and `NO_COLOR` [docker/buildx#1257](https://github.com/docker/buildx),
to customize/disable the colors of interactive build progressbar {% include github_issue.md repo="docker/buildx" number="1230" %} [docker/buildx#1259](https://github.com/docker/buildx/issues/1259)
{% include github_issue.md repo="docker/buildx" number="1226" %} - Buildx now understands environment variable `BUILDKIT_COLORS` and `NO_COLOR`
* `buildx ls` command now shows the current BuildKit version of each builder to customize/disable the colors of interactive build progressbar. [docker/buildx#1230](https://github.com/docker/buildx/issues/1230),
instance {% include github_issue.md repo="docker/buildx" number="998" %} [docker/buildx#1226](https://github.com/docker/buildx/issues/1226)
* The `bake` command now loads `.env` file automatically when building Compose - `buildx ls` command now shows the current BuildKit version of each builder
files for compatibility {% include github_issue.md repo="docker/buildx" number="1261" %} instance. [docker/buildx#998](https://github.com/docker/buildx/issues/998)
* Bake now supports Compose files with `cache_to` definition {% include github_issue.md repo="docker/buildx" number="1155" %} - The `bake` command now loads `.env` file automatically when building Compose
* Bake now supports new builtin function `timestamp()` to access current time {% include github_issue.md repo="docker/buildx" number="1214" %} files for compatibility. [docker/buildx#1261](https://github.com/docker/buildx/issues/1261)
* Bake now supports Compose build secrets definition {% include github_issue.md repo="docker/buildx" number="1069" %} - Bake now supports Compose files with `cache_to` definition. [docker/buildx#1155](https://github.com/docker/buildx/issues/1155)
* Additional build context configuration is now supported in Compose files via `x-bake` {% include github_issue.md repo="docker/buildx" number="1256" %} - Bake now supports new builtin function `timestamp()` to access current time. [docker/buildx#1214](https://github.com/docker/buildx/issues/1214)
* Inspecting builder now shows current driver options configuration {% include github_issue.md repo="docker/buildx" number="1003" %} - Bake now supports Compose build secrets definition. [docker/buildx#1069](https://github.com/docker/buildx/issues/1069)
{% include github_issue.md repo="docker/buildx" number="1066" %} - Additional build context configuration is now supported in Compose files via `x-bake`. [docker/buildx#1256](https://github.com/docker/buildx/issues/1256)
- Inspecting builder now shows current driver options configuration. [docker/buildx#1003](https://github.com/docker/buildx/issues/1003),
[docker/buildx#1066](https://github.com/docker/buildx/issues/1066)
### Updates ### Updates
* Updated the Compose Specification to 1.4.0 {% include github_issue.md repo="docker/buildx" number="1246" %} - Updated the Compose Specification to 1.4.0. [docker/buildx#1246](https://github.com/docker/buildx/issues/1246),
{% include github_issue.md repo="docker/buildx" number="1251" %} [docker/buildx#1251](https://github.com/docker/buildx/issues/1251)
### Bug fixes and enhancements ### Bug fixes and enhancements
* The `buildx ls` command output has been updated with better access to errors - The `buildx ls` command output has been updated with better access to errors
from different builders {% include github_issue.md repo="docker/buildx" number="1109" %} from different builders. [docker/buildx#1109](https://github.com/docker/buildx/issues/1109)
* The `buildx create` command now performs additional validation of builder parameters - The `buildx create` command now performs additional validation of builder parameters
to avoid creating a builder instance with invalid configuration {% include github_issue.md repo="docker/buildx" number="1206" %} to avoid creating a builder instance with invalid configuration. [docker/buildx#1206](https://github.com/docker/buildx/issues/1206)
* The `buildx imagetools create` command can now create new multi-platform images - The `buildx imagetools create` command can now create new multi-platform images
even if the source subimages are located on different repositories or even if the source subimages are located on different repositories or
registries {% include github_issue.md repo="docker/buildx" number="1137" %} registries. [docker/buildx#1137](https://github.com/docker/buildx/issues/1137)
* You can now set the default builder config that is used when creating - You can now set the default builder config that is used when creating
builder instances without passing custom `--config` value {% include github_issue.md repo="docker/buildx" number="1111" %} builder instances without passing custom `--config` value. [docker/buildx#1111](https://github.com/docker/buildx/issues/1111)
* Docker driver can now detect if `dockerd` instance supports initially - Docker driver can now detect if `dockerd` instance supports initially
disabled Buildkit features like multi-platform images {% include github_issue.md repo="docker/buildx" number="1260" %} disabled Buildkit features like multi-platform images. [docker/buildx#1260](https://github.com/docker/buildx/issues/1260),
{% include github_issue.md repo="docker/buildx" number="1262" %} [docker/buildx#1262](https://github.com/docker/buildx/issues/1262)
* Compose files using targets with `.` in the name are now converted to use `_` - Compose files using targets with `.` in the name are now converted to use `_`
so the selector keys can still be used in such targets {% include github_issue.md repo="docker/buildx" number="1011" %} so the selector keys can still be used in such targets. [docker/buildx#1011](https://github.com/docker/buildx/issues/1011)
* Included an additional validation for checking valid driver configurations {% include github_issue.md repo="docker/buildx" number="1188" %} - Included an additional validation for checking valid driver configurations. [docker/buildx#1188](https://github.com/docker/buildx/issues/1188),
{% include github_issue.md repo="docker/buildx" number="1273" %} [docker/buildx#1273](https://github.com/docker/buildx/issues/1273)
* The `remove` command now displays the removed builder and forbids removing - The `remove` command now displays the removed builder and forbids removing
context builders {% include github_issue.md repo="docker/buildx" number="1128" %} context builders. [docker/buildx#1128](https://github.com/docker/buildx/issues/1128)
* Enable Azure authentication when using Kubernetes driver {% include github_issue.md repo="docker/buildx" number="974" %} - Enable Azure authentication when using Kubernetes driver. [docker/buildx#974](https://github.com/docker/buildx/issues/974)
* Add tolerations handling for kubernetes driver {% include github_issue.md repo="docker/buildx" number="1045" %} - Add tolerations handling for kubernetes driver. [docker/buildx#1045](https://github.com/docker/buildx/issues/1045)
{% include github_issue.md repo="docker/buildx" number="1053" %} [docker/buildx#1053](https://github.com/docker/buildx/issues/1053)
* Replace deprecated seccomp annotations with `securityContext` in kubernetes - Replace deprecated seccomp annotations with `securityContext` in the `kubernetes` driver.
driver {% include github_issue.md repo="docker/buildx" number="1052" %} [docker/buildx#1052](https://github.com/docker/buildx/issues/1052)
* Fix panic on handling manifests with nil platform {% include github_issue.md repo="docker/buildx" number="1144" %} - Fix panic on handling manifests with nil platform. [docker/buildx#1144](https://github.com/docker/buildx/issues/1144)
* Fix using duration filter with `prune` command {% include github_issue.md repo="docker/buildx" number="1252" %} - Fix using duration filter with `prune` command. [docker/buildx#1252](https://github.com/docker/buildx/issues/1252)
* Fix merging multiple JSON files on Bake definition {% include github_issue.md repo="docker/buildx" number="1025" %} - Fix merging multiple JSON files on Bake definition. [docker/buildx#1025](https://github.com/docker/buildx/issues/1025)
* Fix issues with implicit builder created from Docker context had invalid - Fix issues with implicit builder created from Docker context had invalid
configuration or dropped connection {% include github_issue.md repo="docker/buildx" number="1129" %} configuration or dropped connection. [docker/buildx#1129](https://github.com/docker/buildx/issues/1129)
* Fix conditions for showing no-output warning when using named contexts {% include github_issue.md repo="docker/buildx" number="968" %} - Fix conditions for showing no-output warning when using named contexts. [docker/buildx#968](https://github.com/docker/buildx/issues/968)
* Fix duplicating builders when builder instance and docker context have the - Fix duplicating builders when builder instance and docker context have the
same name {% include github_issue.md repo="docker/buildx" number="1131" %} same name. [docker/buildx#1131](https://github.com/docker/buildx/issues/1131)
* Fix printing unnecessary SSH warning logs {% include github_issue.md repo="docker/buildx" number="1085" %} - Fix printing unnecessary SSH warning logs. [docker/buildx#1085](https://github.com/docker/buildx/issues/1085)
* Fix possible panic when using an empty variable block with Bake JSON - Fix possible panic when using an empty variable block with Bake JSON
definition {% include github_issue.md repo="docker/buildx" number="1080" %} definition. [docker/buildx#1080](https://github.com/docker/buildx/issues/1080)
* Fix image tools commands not handling `--builder` flag correctly {% include github_issue.md repo="docker/buildx" number="1067" %} - Fix image tools commands not handling `--builder` flag correctly. [docker/buildx#1067](https://github.com/docker/buildx/issues/1067)
* Fix using custom image together with rootless option {% include github_issue.md repo="docker/buildx" number="1063" %} - Fix using custom image together with rootless option. [docker/buildx#1063](https://github.com/docker/buildx/issues/1063)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.9.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.9.0).
## 0.8.2 ## 0.8.2
{{< release-date date="2022-04-04" >}} {{< release-date date="2022-04-04" >}}
### Updates ### Updates
* Update Compose spec used by `buildx bake` to v1.2.1 to fix parsing ports definition {% include github_issue.md repo="docker/buildx" number="1033" %}
- Update Compose spec used by `buildx bake` to v1.2.1 to fix parsing ports definition. [docker/buildx#1033](https://github.com/docker/buildx/issues/1033)
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix possible crash on handling progress streams from BuildKit v0.10 {% include github_issue.md repo="docker/buildx" number="1042" %}
* Fix parsing groups in `buildx bake` when already loaded by a parent group {% include github_issue.md repo="docker/buildx" number="1021" %} - Fix possible crash on handling progress streams from BuildKit v0.10. [docker/buildx#1042](https://github.com/docker/buildx/issues/1042)
- Fix parsing groups in `buildx bake` when already loaded by a parent group. [docker/buildx#1021](https://github.com/docker/buildx/issues/1021)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.2). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.2).
@ -370,8 +384,8 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Bug fixes and enhancements ### Bug fixes and enhancements
* Fix possible panic on handling build context scanning errors {% include github_issue.md repo="docker/buildx" number="1005" %} - Fix possible panic on handling build context scanning errors. [docker/buildx#1005](https://github.com/docker/buildx/issues/1005)
* Allow `.` on Compose target names in `buildx bake` for backward compatibility {% include github_issue.md repo="docker/buildx" number="1018" %} - Allow `.` on Compose target names in `buildx bake` for backward compatibility. [docker/buildx#1018](https://github.com/docker/buildx/issues/1018)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.1).
@ -381,47 +395,50 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New ### New
* Build command now accepts `--build-context` flag to [define additional named build contexts](/engine/reference/commandline/buildx_build/#build-context) - Build command now accepts `--build-context` flag to [define additional named build contexts](/engine/reference/commandline/buildx_build/#build-context)
for your builds {% include github_issue.md repo="docker/buildx" number="904" %} for your builds. [docker/buildx#904](https://github.com/docker/buildx/issues/904)
* Bake definitions now support [defining dependencies between targets](bake/build-contexts.md) - Bake definitions now support [defining dependencies between targets](bake/build-contexts.md)
and using the result of one target in another build {% include github_issue.md repo="docker/buildx" number="928" %} and using the result of one target in another build.
{% include github_issue.md repo="docker/buildx" number="965" %} {% include github_issue.md repo="docker/buildx" number="963" %} [docker/buildx#928](https://github.com/docker/buildx/issues/928),
{% include github_issue.md repo="docker/buildx" number="962" %} {% include github_issue.md repo="docker/buildx" number="981" %} [docker/buildx#965](https://github.com/docker/buildx/issues/965),
* `imagetools inspect` now accepts `--format` flag allowing access to config [docker/buildx#963](https://github.com/docker/buildx/issues/963),
and buildinfo for specific images {% include github_issue.md repo="docker/buildx" number="854" %} [docker/buildx#962](https://github.com/docker/buildx/issues/962),
{% include github_issue.md repo="docker/buildx" number="972" %} [docker/buildx#981](https://github.com/docker/buildx/issues/981)
* New flag `--no-cache-filter` allows configuring build, so it ignores cache - `imagetools inspect` now accepts `--format` flag allowing access to config
only for specified Dockerfile stages {% include github_issue.md repo="docker/buildx" number="860" %} and buildinfo for specific images. [docker/buildx#854](https://github.com/docker/buildx/issues/854),
* Builds can now show a summary of warnings sets by the building frontend {% include github_issue.md repo="docker/buildx" number="892" %} [docker/buildx#972](https://github.com/docker/buildx/issues/972)
* The new build argument `BUILDKIT_INLINE_BUILDINFO_ATTRS` allows opting-in to embed - New flag `--no-cache-filter` allows configuring build, so it ignores cache
building attributes to resulting image {% include github_issue.md repo="docker/buildx" number="908" %} only for specified Dockerfile stages. [docker/buildx#860](https://github.com/docker/buildx/issues/860)
* The new flag `--keep-buildkitd` allows keeping BuildKit daemon running when removing a builder - Builds can now show a summary of warnings sets by the building frontend. [docker/buildx#892](https://github.com/docker/buildx/issues/892)
* {% include github_issue.md repo="docker/buildx" number="852" %} - The new build argument `BUILDKIT_INLINE_BUILDINFO_ATTRS` allows opting-in to embed
building attributes to resulting image. [docker/buildx#908](https://github.com/docker/buildx/issues/908)
- The new flag `--keep-buildkitd` allows keeping BuildKit daemon running when removing a builder
- [docker/buildx#852](https://github.com/docker/buildx/issues/852)
### Bug fixes and enhancements ### Bug fixes and enhancements
* `--metadata-file` output now supports embedded structure types {% include github_issue.md repo="docker/buildx" number="946" %} - `--metadata-file` output now supports embedded structure types. [docker/buildx#946](https://github.com/docker/buildx/issues/946)
* `buildx rm` now accepts new flag `--all-inactive` for removing all builders - `buildx rm` now accepts new flag `--all-inactive` for removing all builders
that are not currently running {% include github_issue.md repo="docker/buildx" number="885" %} that are not currently running. [docker/buildx#885](https://github.com/docker/buildx/issues/885)
* Proxy config is now read from Docker configuration file and sent with build - Proxy config is now read from Docker configuration file and sent with build
requests for backward compatibility {% include github_issue.md repo="docker/buildx" number="959" %} requests for backward compatibility. [docker/buildx#959](https://github.com/docker/buildx/issues/959)
* Support host networking in Compose {% include github_issue.md repo="docker/buildx" number="905" %} - Support host networking in Compose. [docker/buildx#905](https://github.com/docker/buildx/issues/905),
{% include github_issue.md repo="docker/buildx" number="880" %} [docker/buildx#880](https://github.com/docker/buildx/issues/880)
* Bake files can now be read from stdin with `-f -` {% include github_issue.md repo="docker/buildx" number="864" %} - Bake files can now be read from stdin with `-f -`. [docker/buildx#864](https://github.com/docker/buildx/issues/864)
* `--iidfile` now always writes the image config digest independently of the - `--iidfile` now always writes the image config digest independently of the
driver being used (use `--metadata-file` for digest) {% include github_issue.md repo="docker/buildx" number="980" %} driver being used (use `--metadata-file` for digest). [docker/buildx#980](https://github.com/docker/buildx/issues/980)
* Target names in Bake are now restricted to not use special characters {% include github_issue.md repo="docker/buildx" number="929" %} - Target names in Bake are now restricted to not use special characters. [docker/buildx#929](https://github.com/docker/buildx/issues/929)
* Image manifest digest can be read from metadata when pushed with `docker` - Image manifest digest can be read from metadata when pushed with `docker`
driver {% include github_issue.md repo="docker/buildx" number="989" %} driver. [docker/buildx#989](https://github.com/docker/buildx/issues/989)
* Fix environment file handling in Compose files {% include github_issue.md repo="docker/buildx" number="905" %} - Fix environment file handling in Compose files. [docker/buildx#905](https://github.com/docker/buildx/issues/905)
* Show last access time in `du` command {% include github_issue.md repo="docker/buildx" number="867" %} - Show last access time in `du` command. [docker/buildx#867](https://github.com/docker/buildx/issues/867)
* Fix possible double output logs when multiple Bake targets run same build - Fix possible double output logs when multiple Bake targets run same build
steps {% include github_issue.md repo="docker/buildx" number="977" %} steps. [docker/buildx#977](https://github.com/docker/buildx/issues/977)
* Fix possible errors on multi-node builder building multiple targets with - Fix possible errors on multi-node builder building multiple targets with
mixed platform {% include github_issue.md repo="docker/buildx" number="985" %} mixed platform. [docker/buildx#985](https://github.com/docker/buildx/issues/985)
* Fix some nested inheritance cases in Bake {% include github_issue.md repo="docker/buildx" number="914" %} - Fix some nested inheritance cases in Bake. [docker/buildx#914](https://github.com/docker/buildx/issues/914)
* Fix printing default group on Bake files {% include github_issue.md repo="docker/buildx" number="884" %} - Fix printing default group on Bake files. [docker/buildx#884](https://github.com/docker/buildx/issues/884)
* Fix `UsernsMode` when using rootless container {% include github_issue.md repo="docker/buildx" number="887" %} - Fix `UsernsMode` when using rootless container. [docker/buildx#887](https://github.com/docker/buildx/issues/887)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.8.0).
@ -431,8 +448,8 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Fixes ### Fixes
* Fix issue with matching exclude rules in `.dockerignore` {% include github_issue.md repo="docker/buildx" number="858" %} - Fix issue with matching exclude rules in `.dockerignore`. [docker/buildx#858](https://github.com/docker/buildx/issues/858)
* Fix `bake --print` JSON output for current group {% include github_issue.md repo="docker/buildx" number="857" %} - Fix `bake --print` JSON output for current group. [docker/buildx#857](https://github.com/docker/buildx/issues/857)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.7.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.7.1).
@ -442,42 +459,42 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* TLS certificates from BuildKit configuration are now transferred to build - TLS certificates from BuildKit configuration are now transferred to build
container with `docker-container` and `kubernetes` drivers {% include github_issue.md repo="docker/buildx" number="787" %} container with `docker-container` and `kubernetes` drivers. [docker/buildx#787](https://github.com/docker/buildx/issues/787)
* Builds support `--ulimit` flag for feature parity {% include github_issue.md repo="docker/buildx" number="800" %} - Builds support `--ulimit` flag for feature parity. [docker/buildx#800](https://github.com/docker/buildx/issues/800)
* Builds support `--shm-size` flag for feature parity {% include github_issue.md repo="docker/buildx" number="790" %} - Builds support `--shm-size` flag for feature parity. [docker/buildx#790](https://github.com/docker/buildx/issues/790)
* Builds support `--quiet` for feature parity {% include github_issue.md repo="docker/buildx" number="740" %} - Builds support `--quiet` for feature parity. [docker/buildx#740](https://github.com/docker/buildx/issues/740)
* Builds support `--cgroup-parent` flag for feature parity {% include github_issue.md repo="docker/buildx" number="814" %} - Builds support `--cgroup-parent` flag for feature parity. [docker/buildx#814](https://github.com/docker/buildx/issues/814)
* Bake supports builtin variable `BAKE_LOCAL_PLATFORM` {% include github_issue.md repo="docker/buildx" number="748" %} - Bake supports builtin variable `BAKE_LOCAL_PLATFORM`. [docker/buildx#748](https://github.com/docker/buildx/issues/748)
* Bake supports `x-bake` extension field in Compose files {% include github_issue.md repo="docker/buildx" number="721" %} - Bake supports `x-bake` extension field in Compose files. [docker/buildx#721](https://github.com/docker/buildx/issues/721)
* `kubernetes` driver now supports colon-separated `KUBECONFIG` {% include github_issue.md repo="docker/buildx" number="761" %} - `kubernetes` driver now supports colon-separated `KUBECONFIG`. [docker/buildx#761](https://github.com/docker/buildx/issues/761)
* `kubernetes` driver now supports setting Buildkit config file with `--config` {% include github_issue.md repo="docker/buildx" number="682" %} - `kubernetes` driver now supports setting Buildkit config file with `--config`. [docker/buildx#682](https://github.com/docker/buildx/issues/682)
* `kubernetes` driver now supports installing QEMU emulators with driver-opt {% include github_issue.md repo="docker/buildx" number="682" %} - `kubernetes` driver now supports installing QEMU emulators with driver-opt. [docker/buildx#682](https://github.com/docker/buildx/issues/682)
### Enhancements ### Enhancements
* Allow using custom registry configuration for multi-node pushes from the - Allow using custom registry configuration for multi-node pushes from the
client {% include github_issue.md repo="docker/buildx" number="825" %} client. [docker/buildx#825](https://github.com/docker/buildx/issues/825)
* Allow using custom registry configuration for `buildx imagetools` command {% include github_issue.md repo="docker/buildx" number="825" %} - Allow using custom registry configuration for `buildx imagetools` command. [docker/buildx#825](https://github.com/docker/buildx/issues/825)
* Allow booting builder after creating with `buildx create --bootstrap` {% include github_issue.md repo="docker/buildx" number="692" %} - Allow booting builder after creating with `buildx create --bootstrap`. [docker/buildx#692](https://github.com/docker/buildx/issues/692)
* Allow `registry:insecure` output option for multi-node pushes {% include github_issue.md repo="docker/buildx" number="825" %} - Allow `registry:insecure` output option for multi-node pushes. [docker/buildx#825](https://github.com/docker/buildx/issues/825)
* BuildKit config and TLS files are now kept in Buildx state directory and - BuildKit config and TLS files are now kept in Buildx state directory and
reused if BuildKit instance needs to be recreated {% include github_issue.md repo="docker/buildx" number="824" %} reused if BuildKit instance needs to be recreated. [docker/buildx#824](https://github.com/docker/buildx/issues/824)
* Ensure different projects use separate destination directories for - Ensure different projects use separate destination directories for
incremental context transfer for better performance {% include github_issue.md repo="docker/buildx" number="817" %} incremental context transfer for better performance. [docker/buildx#817](https://github.com/docker/buildx/issues/817)
* Build containers are now placed on separate cgroup by default {% include github_issue.md repo="docker/buildx" number="782" %} - Build containers are now placed on separate cgroup by default. [docker/buildx#782](https://github.com/docker/buildx/issues/782)
* Bake now prints the default group with `--print` {% include github_issue.md repo="docker/buildx" number="720" %} - Bake now prints the default group with `--print`. [docker/buildx#720](https://github.com/docker/buildx/issues/720)
* `docker` driver now dials build session over HTTP for better performance {% include github_issue.md repo="docker/buildx" number="804" %} - `docker` driver now dials build session over HTTP for better performance. [docker/buildx#804](https://github.com/docker/buildx/issues/804)
### Fixes ### Fixes
* Fix using `--iidfile` together with a multi-node push {% include github_issue.md repo="docker/buildx" number="826" %} - Fix using `--iidfile` together with a multi-node push. [docker/buildx#826](https://github.com/docker/buildx/issues/826)
* Using `--push` in Bake does not clear other image export options in the file {% include github_issue.md repo="docker/buildx" number="773" %} - Using `--push` in Bake does not clear other image export options in the file. [docker/buildx#773](https://github.com/docker/buildx/issues/773)
* Fix Git URL detection for `buildx bake` when `https` protocol was used {% include github_issue.md repo="docker/buildx" number="822" %} - Fix Git URL detection for `buildx bake` when `https` protocol was used. [docker/buildx#822](https://github.com/docker/buildx/issues/822)
* Fix pushing image with multiple names on multi-node builds {% include github_issue.md repo="docker/buildx" number="815" %} - Fix pushing image with multiple names on multi-node builds. [docker/buildx#815](https://github.com/docker/buildx/issues/815)
* Avoid showing `--builder` flags for commands that don't use it {% include github_issue.md repo="docker/buildx" number="818" %} - Avoid showing `--builder` flags for commands that don't use it. [docker/buildx#818](https://github.com/docker/buildx/issues/818)
* Unsupported build flags now show a warning {% include github_issue.md repo="docker/buildx" number="810" %} - Unsupported build flags now show a warning. [docker/buildx#810](https://github.com/docker/buildx/issues/810)
* Fix reporting error details in some OpenTelemetry traces {% include github_issue.md repo="docker/buildx" number="812" %} - Fix reporting error details in some OpenTelemetry traces. [docker/buildx#812](https://github.com/docker/buildx/issues/812)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.7.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.7.0).
@ -487,7 +504,7 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Fixes ### Fixes
* Fix BuildKit state volume location for Windows clients {% include github_issue.md repo="docker/buildx" number="751" %} - Fix BuildKit state volume location for Windows clients. [docker/buildx#751](https://github.com/docker/buildx/issues/751)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.3). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.3).
@ -499,7 +516,7 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Fixes ### Fixes
* Fix connection error showing up in some SSH configurations {% include github_issue.md repo="docker/buildx" number="741" %} - Fix connection error showing up in some SSH configurations. [docker/buildx#741](https://github.com/docker/buildx/issues/741)
## 0.6.1 ## 0.6.1
@ -507,12 +524,12 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Enhancements ### Enhancements
* Set `ConfigFile` to parse compose files with Bake {% include github_issue.md repo="docker/buildx" number="704" %} - Set `ConfigFile` to parse compose files with Bake. [docker/buildx#704](https://github.com/docker/buildx/issues/704)
### Fixes ### Fixes
* Duplicate progress env var {% include github_issue.md repo="docker/buildx" number="693" %} - Duplicate progress env var. [docker/buildx#693](https://github.com/docker/buildx/issues/693)
* Should ignore nil client {% include github_issue.md repo="docker/buildx" number="686" %} - Should ignore nil client. [docker/buildx#686](https://github.com/docker/buildx/issues/686)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.1).
@ -522,46 +539,48 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* Support for OpenTelemetry traces and forwarding Buildx client traces to - Support for OpenTelemetry traces and forwarding Buildx client traces to
BuildKit {% include github_issue.md repo="docker/buildx" number="635" %} BuildKit. [docker/buildx#635](https://github.com/docker/buildx/issues/635)
* Experimental GitHub Actions remote cache backend with `--cache-to type=gha` - Experimental GitHub Actions remote cache backend with `--cache-to type=gha`
and `--cache-from type=gha` {% include github_issue.md repo="docker/buildx" number="535" %} and `--cache-from type=gha`. [docker/buildx#535](https://github.com/docker/buildx/issues/535)
* New `--metadata-file` flag has been added to build and Bake command that - New `--metadata-file` flag has been added to build and Bake command that
allows saving build result metadata in JSON format {% include github_issue.md repo="docker/buildx" number="605" %} allows saving build result metadata in JSON format. [docker/buildx#605](https://github.com/docker/buildx/issues/605)
* This is the first release supporting Windows ARM64 {% include github_issue.md repo="docker/buildx" number="654" %} - This is the first release supporting Windows ARM64. [docker/buildx#654](https://github.com/docker/buildx/issues/654)
* This is the first release supporting Linux Risc-V {% include github_issue.md repo="docker/buildx" number="652" %} - This is the first release supporting Linux Risc-V. [docker/buildx#652](https://github.com/docker/buildx/issues/652)
* Bake now supports building from remote definition with local files or - Bake now supports building from remote definition with local files or
another remote source as context {% include github_issue.md repo="docker/buildx" number="671" %} another remote source as context. [docker/buildx#671](https://github.com/docker/buildx/issues/671)
* Bake now allows variables to reference each other and using user functions - Bake now allows variables to reference each other and using user functions
in variables and vice-versa {% include github_issue.md repo="docker/buildx" number="575" %} in variables and vice-versa.
{% include github_issue.md repo="docker/buildx" number="539" %} {% include github_issue.md repo="docker/buildx" number="532" %} [docker/buildx#575](https://github.com/docker/buildx/issues/575),
* Bake allows defining attributes in the global scope {% include github_issue.md repo="docker/buildx" number="541" %} [docker/buildx#539](https://github.com/docker/buildx/issues/539),
* Bake allows variables across multiple files {% include github_issue.md repo="docker/buildx" number="538" %} [docker/buildx#532](https://github.com/docker/buildx/issues/532)
* New quiet mode has been added to progress printer {% include github_issue.md repo="docker/buildx" number="558" %} - Bake allows defining attributes in the global scope. [docker/buildx#541](https://github.com/docker/buildx/issues/541)
* `kubernetes` driver now supports defining resources/limits {% include github_issue.md repo="docker/buildx" number="618" %} - Bake allows variables across multiple files. [docker/buildx#538](https://github.com/docker/buildx/issues/538)
* Buildx binaries can now be accessed through [buildx-bin](https://hub.docker.com/r/docker/buildx-bin) - New quiet mode has been added to progress printer. [docker/buildx#558](https://github.com/docker/buildx/issues/558)
Docker image {% include github_issue.md repo="docker/buildx" number="656" %} - `kubernetes` driver now supports defining resources/limits. [docker/buildx#618](https://github.com/docker/buildx/issues/618)
- Buildx binaries can now be accessed through [buildx-bin](https://hub.docker.com/r/docker/buildx-bin)
Docker image. [docker/buildx#656](https://github.com/docker/buildx/issues/656)
### Enhancements ### Enhancements
* `docker-container` driver now keeps BuildKit state in volume. Enabling - `docker-container` driver now keeps BuildKit state in volume. Enabling
updates with keeping state {% include github_issue.md repo="docker/buildx" number="672" %} updates with keeping state. [docker/buildx#672](https://github.com/docker/buildx/issues/672)
* Compose parser is now based on new [compose-go parser](https://github.com/compose-spec/compose-go) - Compose parser is now based on new [compose-go parser](https://github.com/compose-spec/compose-go)
fixing support for some newer syntax {% include github_issue.md repo="docker/buildx" number="669" %} fixing support for some newer syntax. [docker/buildx#669](https://github.com/docker/buildx/issues/669)
* SSH socket is now automatically forwarded when building an ssh-based git URL {% include github_issue.md repo="docker/buildx" number="581" %} - SSH socket is now automatically forwarded when building an ssh-based git URL. [docker/buildx#581](https://github.com/docker/buildx/issues/581)
* Bake HCL parser has been rewritten {% include github_issue.md repo="docker/buildx" number="645" %} - Bake HCL parser has been rewritten. [docker/buildx#645](https://github.com/docker/buildx/issues/645)
* Extend HCL support with more functions {% include github_issue.md repo="docker/buildx" number="491" %} - Extend HCL support with more functions. [docker/buildx#491](https://github.com/docker/buildx/issues/491)
{% include github_issue.md repo="docker/buildx" number="503" %} [docker/buildx#503](https://github.com/docker/buildx/issues/503)
* Allow secrets from environment variables {% include github_issue.md repo="docker/buildx" number="488" %} - Allow secrets from environment variables. [docker/buildx#488](https://github.com/docker/buildx/issues/488)
* Builds with an unsupported multi-platform and load configuration now fail fast {% include github_issue.md repo="docker/buildx" number="582" %} - Builds with an unsupported multi-platform and load configuration now fail fast. [docker/buildx#582](https://github.com/docker/buildx/issues/582)
* Store Kubernetes config file to make buildx builder switchable {% include github_issue.md repo="docker/buildx" number="497" %} - Store Kubernetes config file to make buildx builder switchable. [docker/buildx#497](https://github.com/docker/buildx/issues/497)
* Kubernetes now lists all pods as nodes on inspection {% include github_issue.md repo="docker/buildx" number="477" %} - Kubernetes now lists all pods as nodes on inspection. [docker/buildx#477](https://github.com/docker/buildx/issues/477)
* Default Rootless image has been set to `moby/buildkit:buildx-stable-1-rootless` {% include github_issue.md repo="docker/buildx" number="480" %} - Default Rootless image has been set to `moby/buildkit:buildx-stable-1-rootless`. [docker/buildx#480](https://github.com/docker/buildx/issues/480)
### Fixes ### Fixes
* `imagetools create` command now correctly merges JSON descriptor with old one {% include github_issue.md repo="docker/buildx" number="592" %} - `imagetools create` command now correctly merges JSON descriptor with old one. [docker/buildx#592](https://github.com/docker/buildx/issues/592)
* Fix building with `--network=none` not requiring extra security entitlements {% include github_issue.md repo="docker/buildx" number="531" %} - Fix building with `--network=none` not requiring extra security entitlements. [docker/buildx#531](https://github.com/docker/buildx/issues/531)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.6.0).
@ -571,8 +590,8 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Fixes ### Fixes
* Fix regression on setting `--platform` on `buildx create` outside - Fix regression on setting `--platform` on `buildx create` outside
`kubernetes` driver {% include github_issue.md repo="docker/buildx" number="475" %} `kubernetes` driver. [docker/buildx#475](https://github.com/docker/buildx/issues/475)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.5.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.5.1).
@ -582,38 +601,41 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* The `docker` driver now supports the `--push` flag {% include github_issue.md repo="docker/buildx" number="442" %} - The `docker` driver now supports the `--push` flag. [docker/buildx#442](https://github.com/docker/buildx/issues/442)
* Bake supports inline Dockerfiles {% include github_issue.md repo="docker/buildx" number="398" %} - Bake supports inline Dockerfiles. [docker/buildx#398](https://github.com/docker/buildx/issues/398)
* Bake supports building from remote URLs and Git repositories {% include github_issue.md repo="docker/buildx" number="398" %} - Bake supports building from remote URLs and Git repositories. [docker/buildx#398](https://github.com/docker/buildx/issues/398)
* `BUILDX_CONFIG` env var allow users to have separate buildx state from - `BUILDX_CONFIG` env var allow users to have separate buildx state from
Docker config {% include github_issue.md repo="docker/buildx" number="385" %} Docker config. [docker/buildx#385](https://github.com/docker/buildx/issues/385)
* `BUILDKIT_MULTI_PLATFORM` build arg allows to force building multi-platform - `BUILDKIT_MULTI_PLATFORM` build arg allows to force building multi-platform
return objects even if only one `--platform` specified {% include github_issue.md repo="docker/buildx" number="467" %} return objects even if only one `--platform` specified. [docker/buildx#467](https://github.com/docker/buildx/issues/467)
### Enhancements ### Enhancements
* Allow `--append` to be used with `kubernetes` driver {% include github_issue.md repo="docker/buildx" number="370" %} - Allow `--append` to be used with `kubernetes` driver. [docker/buildx#370](https://github.com/docker/buildx/issues/370)
* Build errors show error location in source files and system stacktraces - Build errors show error location in source files and system stacktraces
with `--debug` {% include github_issue.md repo="docker/buildx" number="389" %} with `--debug`. [docker/buildx#389](https://github.com/docker/buildx/issues/389)
* Bake formats HCL errors with source definition {% include github_issue.md repo="docker/buildx" number="391" %} - Bake formats HCL errors with source definition. [docker/buildx#391](https://github.com/docker/buildx/issues/391)
* Bake allows empty string values in arrays that will be discarded {% include github_issue.md repo="docker/buildx" number="428" %} - Bake allows empty string values in arrays that will be discarded. [docker/buildx#428](https://github.com/docker/buildx/issues/428)
* You can now use the Kubernetes cluster config with the `kubernetes` driver {% include github_issue.md repo="docker/buildx" number="368" %} - You can now use the Kubernetes cluster config with the `kubernetes` driver. [docker/buildx#368](https://github.com/docker/buildx/issues/368)
{% include github_issue.md repo="docker/buildx" number="460" %} [docker/buildx#460](https://github.com/docker/buildx/issues/460)
* Creates a temporary token for pulling images instead of sharing credentials - Creates a temporary token for pulling images instead of sharing credentials
when possible {% include github_issue.md repo="docker/buildx" number="469" %} when possible. [docker/buildx#469](https://github.com/docker/buildx/issues/469)
* Ensure credentials are passed when pulling BuildKit container image {% include github_issue.md repo="docker/buildx" number="441" %} - Ensure credentials are passed when pulling BuildKit container image. [docker/buildx#441](https://github.com/docker/buildx/issues/441)
{% include github_issue.md repo="docker/buildx" number="433" %} [docker/buildx#433](https://github.com/docker/buildx/issues/433)
* Disable user namespace remapping in `docker-container` driver {% include github_issue.md repo="docker/buildx" number="462" %} - Disable user namespace remapping in `docker-container` driver. [docker/buildx#462](https://github.com/docker/buildx/issues/462)
* Allow `--builder` flag to switch to default instance {% include github_issue.md repo="docker/buildx" number="425" %} - Allow `--builder` flag to switch to default instance. [docker/buildx#425](https://github.com/docker/buildx/issues/425)
* Avoid warn on empty `BUILDX_NO_DEFAULT_LOAD` config value {% include github_issue.md repo="docker/buildx" number="390" %} - Avoid warn on empty `BUILDX_NO_DEFAULT_LOAD` config value. [docker/buildx#390](https://github.com/docker/buildx/issues/390)
* Replace error generated by `quiet` option by a warning {% include github_issue.md repo="docker/buildx" number="403" %} - Replace error generated by `quiet` option by a warning. [docker/buildx#403](https://github.com/docker/buildx/issues/403)
* CI has been switched to GitHub Actions {% include github_issue.md repo="docker/buildx" number="451" %} - CI has been switched to GitHub Actions.
{% include github_issue.md repo="docker/buildx" number="463" %} {% include github_issue.md repo="docker/buildx" number="466" %} [docker/buildx#451](https://github.com/docker/buildx/issues/451),
{% include github_issue.md repo="docker/buildx" number="468" %} {% include github_issue.md repo="docker/buildx" number="471" %} [docker/buildx#463](https://github.com/docker/buildx/issues/463),
[docker/buildx#466](https://github.com/docker/buildx/issues/466),
[docker/buildx#468](https://github.com/docker/buildx/issues/468),
[docker/buildx#471](https://github.com/docker/buildx/issues/471)
### Fixes ### Fixes
* Handle lowercase Dockerfile name as a fallback for backward compatibility {% include github_issue.md repo="docker/buildx" number="444" %} - Handle lowercase Dockerfile name as a fallback for backward compatibility. [docker/buildx#444](https://github.com/docker/buildx/issues/444)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.5.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.5.0).
@ -623,18 +645,18 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* Support `cacheonly` exporter {% include github_issue.md repo="docker/buildx" number="337" %} - Support `cacheonly` exporter. [docker/buildx#337](https://github.com/docker/buildx/issues/337)
### Enhancements ### Enhancements
* Update `go-cty` to pull in more `stdlib` functions {% include github_issue.md repo="docker/buildx" number="277" %} - Update `go-cty` to pull in more `stdlib` functions. [docker/buildx#277](https://github.com/docker/buildx/issues/277)
* Improve error checking on load {% include github_issue.md repo="docker/buildx" number="281" %} - Improve error checking on load. [docker/buildx#281](https://github.com/docker/buildx/issues/281)
### Fixes ### Fixes
* Fix parsing json config with HCL {% include github_issue.md repo="docker/buildx" number="280" %} - Fix parsing json config with HCL. [docker/buildx#280](https://github.com/docker/buildx/issues/280)
* Ensure `--builder` is wired from root options {% include github_issue.md repo="docker/buildx" number="321" %} - Ensure `--builder` is wired from root options. [docker/buildx#321](https://github.com/docker/buildx/issues/321)
* Remove warning for multi-platform iidfile {% include github_issue.md repo="docker/buildx" number="351" %} - Remove warning for multi-platform iidfile. [docker/buildx#351](https://github.com/docker/buildx/issues/351)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.2). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.2).
@ -644,8 +666,8 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Fixes ### Fixes
* Fix regression on flag parsing {% include github_issue.md repo="docker/buildx" number="268" %} - Fix regression on flag parsing. [docker/buildx#268](https://github.com/docker/buildx/issues/268)
* Fix using pull and no-cache keys in HCL targets {% include github_issue.md repo="docker/buildx" number="268" %} - Fix using pull and no-cache keys in HCL targets. [docker/buildx#268](https://github.com/docker/buildx/issues/268)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.1).
@ -655,17 +677,17 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* Add `kubernetes` driver {% include github_issue.md repo="docker/buildx" number="167" %} - Add `kubernetes` driver. [docker/buildx#167](https://github.com/docker/buildx/issues/167)
* New global `--builder` flag to override builder instance for a single command {% include github_issue.md repo="docker/buildx" number="246" %} - New global `--builder` flag to override builder instance for a single command. [docker/buildx#246](https://github.com/docker/buildx/issues/246)
* New `prune` and `du` commands for managing local builder cache {% include github_issue.md repo="docker/buildx" number="249" %} - New `prune` and `du` commands for managing local builder cache. [docker/buildx#249](https://github.com/docker/buildx/issues/249)
* You can now set the new `pull` and `no-cache` options for HCL targets {% include github_issue.md repo="docker/buildx" number="165" %} - You can now set the new `pull` and `no-cache` options for HCL targets. [docker/buildx#165](https://github.com/docker/buildx/issues/165)
### Enhancements ### Enhancements
* Upgrade Bake to HCL2 with support for variables and functions {% include github_issue.md repo="docker/buildx" number="192" %} - Upgrade Bake to HCL2 with support for variables and functions. [docker/buildx#192](https://github.com/docker/buildx/issues/192)
* Bake now supports `--load` and `--push` {% include github_issue.md repo="docker/buildx" number="164" %} - Bake now supports `--load` and `--push`. [docker/buildx#164](https://github.com/docker/buildx/issues/164)
* Bake now supports wildcard overrides for multiple targets {% include github_issue.md repo="docker/buildx" number="164" %} - Bake now supports wildcard overrides for multiple targets. [docker/buildx#164](https://github.com/docker/buildx/issues/164)
* Container driver allows setting environment variables via `driver-opt` {% include github_issue.md repo="docker/buildx" number="170" %} - Container driver allows setting environment variables via `driver-opt`. [docker/buildx#170](https://github.com/docker/buildx/issues/170)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.4.0).
@ -675,13 +697,14 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Enhancements ### Enhancements
* Handle copying unix sockets instead of erroring {% include github_issue.md repo="docker/buildx" number="155" %} - Handle copying unix sockets instead of erroring. [docker/buildx#155](https://github.com/docker/buildx/issues/155)
{% include github_issue.md repo="moby/buildkit" number="1144" %} [moby/buildkit#1144](https://github.com/moby/buildkit/issues/1144)
### Fixes ### Fixes
* Running Bake with multiple Compose files now merges targets correctly {% include github_issue.md repo="docker/buildx" number="134" %} - Running Bake with multiple Compose files now merges targets correctly. [docker/buildx#134](https://github.com/docker/buildx/issues/134)
* Fix bug when building a Dockerfile from stdin (`build -f -`) {% include github_issue.md repo="docker/buildx" number="153" %} - Fix bug when building a Dockerfile from stdin (`build -f -`).
[docker/buildx#153](https://github.com/docker/buildx/issues/153)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.3.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.3.1).
@ -691,19 +714,19 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* Custom `buildkitd` daemon flags {% include github_issue.md repo="docker/buildx" number="102" %} - Custom `buildkitd` daemon flags. [docker/buildx#102](https://github.com/docker/buildx/issues/102)
* Driver-specific options on `create` {% include github_issue.md repo="docker/buildx" number="122" %} - Driver-specific options on `create`. [docker/buildx#122](https://github.com/docker/buildx/issues/122)
### Enhancements ### Enhancements
* Environment variables are used in Compose files {% include github_issue.md repo="docker/buildx" number="117" %} - Environment variables are used in Compose files. [docker/buildx#117](https://github.com/docker/buildx/issues/117)
* Bake now honors `--no-cache` and `--pull` {% include github_issue.md repo="docker/buildx" number="118" %} - Bake now honors `--no-cache` and `--pull`. [docker/buildx#118](https://github.com/docker/buildx/issues/118)
* Custom BuildKit config file {% include github_issue.md repo="docker/buildx" number="121" %} - Custom BuildKit config file. [docker/buildx#121](https://github.com/docker/buildx/issues/121)
* Entitlements support with `build --allow` {% include github_issue.md repo="docker/buildx" number="104" %} - Entitlements support with `build --allow`. [docker/buildx#104](https://github.com/docker/buildx/issues/104)
### Fixes ### Fixes
* Fix bug where `--build-arg foo` would not read `foo` from environment {% include github_issue.md repo="docker/buildx" number="116" %} - Fix bug where `--build-arg foo` would not read `foo` from environment. [docker/buildx#116](https://github.com/docker/buildx/issues/116)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.3.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.3.0).
@ -713,7 +736,7 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### Enhancements ### Enhancements
* Change Compose file handling to require valid service specifications {% include github_issue.md repo="docker/buildx" number="87" %} - Change Compose file handling to require valid service specifications. [docker/buildx#87](https://github.com/docker/buildx/issues/87)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.2). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.2).
@ -723,17 +746,17 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* Add `BUILDKIT_PROGRESS` env var {% include github_issue.md repo="docker/buildx" number="69" %} - Add `BUILDKIT_PROGRESS` env var. [docker/buildx#69](https://github.com/docker/buildx/issues/69)
* Add `local` platform {% include github_issue.md repo="docker/buildx" number="70" %} - Add `local` platform. [docker/buildx#70](https://github.com/docker/buildx/issues/70)
### Enhancements ### Enhancements
* Keep arm variant if one is defined in the config {% include github_issue.md repo="docker/buildx" number="68" %} - Keep arm variant if one is defined in the config. [docker/buildx#68](https://github.com/docker/buildx/issues/68)
* Make dockerfile relative to context {% include github_issue.md repo="docker/buildx" number="83" %} - Make dockerfile relative to context. [docker/buildx#83](https://github.com/docker/buildx/issues/83)
### Fixes ### Fixes
* Fix parsing target from compose files {% include github_issue.md repo="docker/buildx" number="53" %} - Fix parsing target from compose files. [docker/buildx#53](https://github.com/docker/buildx/issues/53)
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.1). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.1).
@ -743,6 +766,6 @@ For more details, see the complete release notes in the [Buildx GitHub repositor
### New features ### New features
* First release - First release
For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.0). For more details, see the complete release notes in the [Buildx GitHub repository](https://github.com/docker/buildx/releases/tag/v0.2.0).

4
data/toc.yaml
View File

@ -1718,8 +1718,8 @@ Manuals:
title: Bake file reference title: Bake file reference
- path: /build/bake/configuring-build/ - path: /build/bake/configuring-build/
title: Configuring builds title: Configuring builds
- path: /build/bake/hcl-funcs/ - path: /build/bake/advanced/
title: User defined HCL functions title: Advanced patterns
- path: /build/bake/build-contexts/ - path: /build/bake/build-contexts/
title: Build contexts and linking targets title: Build contexts and linking targets
- path: /build/bake/compose-file/ - path: /build/bake/compose-file/