docker/buildx
1
0
Fork 0
mirror of https://gitea.com/Lydanne/buildx.git synced 2025-07-09 21:17:09 +08:00
Code Issues Packages Projects Releases 1 Wiki Activity

docs: address some review comments from the docs repository

Browse Source 
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This commit is contained in:
Sebastiaan van Stijn
2021-04-07 16:04:11 +02:00
parent adc5f35237
commit cd3a9ad38d
5 changed files with 15 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
docs/reference/buildx_build.md
View File

@ -45,7 +45,7 @@ Start a build
The `buildx build` command starts a build using BuildKit. This command is similar
to the UI of `docker build` command and takes the same flags and arguments.
For documentation on most of these flags refer to the [`docker build`
For documentation on most of these flags, refer to the [`docker build`
documentation](https://docs.docker.com/engine/reference/commandline/build/). In
here we’ll document a subset of the new flags.
@ -67,12 +67,12 @@ values as an input separated by a comma. With multiple values the result will be
built for all of the specified platforms and joined together into a single manifest
list.
If the`Dockerfile` needs to invoke the `RUN` command, the builder needs runtime
If the `Dockerfile` needs to invoke the `RUN` command, the builder needs runtime
support for the specified platform. In a clean setup, you can only execute `RUN`
commands for your system architecture.
If your kernel supports [`binfmt_misc`](https://en.wikipedia.org/wiki/Binfmt_misc)
launchers for secondary architectures buildx will pick them up automatically.
Docker desktop releases come with binfmt_misc automatically configured for `arm64`
launchers for secondary architectures, buildx will pick them up automatically.
Docker desktop releases come with `binfmt_misc` automatically configured for `arm64`
and `arm` architectures. You can see what runtime platforms your current builder
instance supports by running `docker buildx inspect --bootstrap`.
@ -171,7 +171,7 @@ tar will be loaded automatically to the current docker instance.
#### `image`
The `image` exporter writes the build result as an image or a manifest list. When
using `docker` driver the image will appear in `docker images`. Optionally image
using `docker` driver the image will appear in `docker images`. Optionally, image
can be automatically pushed to a registry by specifying attributes.
Attribute keys:

4
docs/reference/buildx_create.md
View File

@ -33,11 +33,11 @@ Create makes a new builder instance pointing to a docker context or endpoint,
where context is the name of a context from `docker context ls` and endpoint is
the address for docker socket (eg. `DOCKER_HOST` value).
By default, the current docker configuration is used for determining the
By default, the current Docker configuration is used for determining the
context/endpoint value.
Builder instances are isolated environments where builds can be invoked. All
docker contexts also get the default builder instance.
Docker contexts also get the default builder instance.
## Examples

8
docs/reference/buildx_imagetools_create.md
View File

@ -25,10 +25,10 @@ Create a new image based on source images
Imagetools contains commands for working with manifest lists in the registry.
These commands are useful for inspecting multi-platform build results.
Create creates a new manifest list based on source manifests. The source
manifests can be manifest lists or single platform distribution manifests and
must already exist in the registry where the new manifest is created. If only
one source is specified create performs a carbon copy.
Create a new manifest list based on source manifests. The source manifests can
be manifest lists or single platform distribution manifests and must already
exist in the registry where the new manifest is created. If only one source is
specified, create performs a carbon copy.
## Examples

4
docs/reference/buildx_inspect.md
View File

@ -50,9 +50,9 @@ Platforms: linux/arm64, linux/arm/v7, linux/arm/v6
### <a name="bootstrap"></a> Ensure that the builder is running before inspecting (--bootstrap)
Use the `--bootstrap` option to ensures that the builder is running before
Use the `--bootstrap` option to ensure that the builder is running before
inspecting it. If the driver is `docker-container`, then `--bootstrap` starts
the buildkit container and waits until it is operational. Bootstrapping is
automatically done during build, it is thus not necessary. The same BuildKit
automatically done during build, and therefore not necessary. The same BuildKit
container is used during the lifetime of the associated builder node (as
displayed in `buildx ls`).