docs: minor cli reference editorial updates

Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>

docs/reference/buildx.md

@@ -1,6 +1,6 @@
 # buildx
 
-```
+```text
 docker buildx [OPTIONS] COMMAND
 ```
 

docs/reference/buildx_bake.md

@@ -1,6 +1,6 @@
 # buildx bake
 
-```
+```text
 docker buildx bake [OPTIONS] [TARGET...]
 ```
 
@@ -33,7 +33,7 @@ Build from a file
 
 ## Description
 
-Bake is a high-level build command. Each specified target will run in parallel
+Bake is a high-level build command. Each specified target runs in parallel
 as part of the build.
 
 Read [High-level build options with Bake](https://docs.docker.com/build/bake/)
@@ -54,8 +54,8 @@ Same as [`buildx --builder`](buildx.md#builder).
 ### <a name="file"></a> Specify a build definition file (-f, --file)
 
 Use the `-f` / `--file` option to specify the build definition file to use.
-The file can be an HCL, JSON or Compose file. If multiple files are specified
+The file can be an HCL, JSON or Compose file. If multiple files are specified,
-they are all read and configurations are combined.
+all are read and the build configurations are combined.
 
 You can pass the names of the targets to build, to build only specific target(s).
 The following example builds the `db` and `webapp-release` targets that are
@@ -90,9 +90,9 @@ $ docker buildx bake -f docker-bake.dev.hcl db webapp-release
 See the [Bake file reference](https://docs.docker.com/build/bake/reference/)
 for more details.
 
-### <a name="no-cache"></a> Do not use cache when building the image (--no-cache)
+### <a name="no-cache"></a> Don't use cache when building the image (--no-cache)
 
-Same as `build --no-cache`. Do not use cache when building the image.
+Same as `build --no-cache`. Don't use cache when building the image.
 
 ### <a name="print"></a> Print the options without building (--print)
 
@@ -154,7 +154,7 @@ $ docker buildx bake --set *.platform=linux/arm64     # overrides platform for a
 $ docker buildx bake --set foo*.no-cache              # bypass caching only for targets starting with 'foo'
 ```
 
-Complete list of overridable fields:
+You can override the following fields:
 
 * `args`
 * `cache-from`

docs/reference/buildx_build.md

@@ -1,6 +1,6 @@
 # buildx build
 
-```
+```text
 docker buildx build [OPTIONS] PATH | URL | -
 ```
 
@@ -64,14 +64,14 @@ The `buildx build` command starts a build using BuildKit. This command is simila
 to the UI of `docker build` command and takes the same flags and arguments.
 
 For documentation on most of these flags, refer to the [`docker build`
-documentation](https://docs.docker.com/engine/reference/commandline/build/). In
+documentation](https://docs.docker.com/engine/reference/commandline/build/).
-here we'll document a subset of the new flags.
+This page describes a subset of the new flags.
 
 ## Examples
 
 ### <a name="attest"></a> Create attestations (--attest)
 
-```
+```text
 --attest=type=sbom,...
 --attest=type=provenance,...
 ```
@@ -98,7 +98,7 @@ BuildKit currently supports:
 
 ### <a name="allow"></a> Allow extra privileged entitlement (--allow)
 
-```
+```text
 --allow=ENTITLEMENT
 ```
 
@@ -109,9 +109,7 @@ Allow extra privileged entitlement. List of entitlements:
   [related Dockerfile extensions](https://docs.docker.com/engine/reference/builder/#run---securitysandbox).
 
 For entitlements to be enabled, the `buildkitd` daemon also needs to allow them
-with `--allow-insecure-entitlement` (see [`create --buildkitd-flags`](buildx_create.md#buildkitd-flags))
+with `--allow-insecure-entitlement` (see [`create --buildkitd-flags`](buildx_create.md#buildkitd-flags)).
-
-**Examples**
 
 ```console
 $ docker buildx create --use --name insecure-builder --buildkitd-flags '--allow-insecure-entitlement security.insecure'
@@ -122,23 +120,21 @@ $ docker buildx build --allow security.insecure .
 
 Same as [`docker build` command](https://docs.docker.com/engine/reference/commandline/build/#build-arg).
 
-There are also useful built-in build args like:
+There are also useful built-in build arguments, such as:
 
-* `BUILDKIT_CONTEXT_KEEP_GIT_DIR=<bool>` trigger git context to keep the `.git` directory
+* `BUILDKIT_CONTEXT_KEEP_GIT_DIR=<bool>`: trigger git context to keep the `.git` directory
-* `BUILDKIT_INLINE_CACHE=<bool>` inline cache metadata to image config or not
+* `BUILDKIT_INLINE_CACHE=<bool>`: inline cache metadata to image config or not
-* `BUILDKIT_MULTI_PLATFORM=<bool>` opt into deterministic output regardless of multi-platform output or not
+* `BUILDKIT_MULTI_PLATFORM=<bool>`: opt into deterministic output regardless of multi-platform output or not
 
 ```console
 $ docker buildx build --build-arg BUILDKIT_MULTI_PLATFORM=1 .
 ```
 
-> **Note**
+Learn more about the built-in build arguments in the [Dockerfile reference docs](https://docs.docker.com/engine/reference/builder/#buildkit-built-in-build-args).
->
-> More built-in build args can be found in [Dockerfile reference docs](https://docs.docker.com/engine/reference/builder/#buildkit-built-in-build-args).
 
 ### <a name="build-context"></a> Additional build contexts (--build-context)
 
-```
+```text
 --build-context=name=VALUE
 ```
 
@@ -166,7 +162,7 @@ FROM alpine
 COPY --from=project myfile /
 ```
 
-#### <a name="source-oci-layout"></a> Source image from OCI layout directory
+#### <a name="source-oci-layout"></a> Use an OCI layout directory as build context
 
 Source an image from a local [OCI layout compliant directory](https://github.com/opencontainers/image-spec/blob/main/image-layout.md),
 either by tag, or by digest:
@@ -194,7 +190,7 @@ Same as [`buildx --builder`](buildx.md#builder).
 
 ### <a name="cache-from"></a> Use an external cache source for a build (--cache-from)
 
-```
+```text
 --cache-from=[NAME|type=TYPE[,KEY=VALUE]]
 ```
 
@@ -230,7 +226,7 @@ More info about cache exporters and available attributes: https://github.com/mob
 
 ### <a name="cache-to"></a> Export build cache to an external cache destination (--cache-to)
 
-```
+```text
 --cache-to=[NAME|type=TYPE[,KEY=VALUE]]
 ```
 
@@ -247,9 +243,8 @@ Export build cache to an external cache destination. Supported types are
 - [`s3` type](https://github.com/moby/buildkit#s3-cache-experimental) exports
   cache to a S3 bucket.
 
-`docker` driver currently only supports exporting inline cache metadata to image
+The `docker` driver only supports cache exports using the `inline` and `local`
-configuration. Alternatively, `--build-arg BUILDKIT_INLINE_CACHE=1` can be used
+cache backends.
-to trigger inline cache exporter.
 
 Attribute key:
 
@@ -283,6 +278,7 @@ directory of the specified file must already exist and be writable.
 $ docker buildx build --load --metadata-file metadata.json .
 $ cat metadata.json
 ```
+
 ```json
 {
   "containerimage.config.digest": "sha256:2937f66a9722f7f4a2df583de2f8cb97fc9196059a410e7f00072fc918930e66",
@@ -301,14 +297,14 @@ $ cat metadata.json
 
 ### <a name="output"></a> Set the export action for the build result (-o, --output)
 
-```
+```text
 -o, --output=[PATH,-,type=TYPE[,KEY=VALUE]
 ```
 
 Sets the export action for the build result. In `docker build` all builds finish
 by creating a container image and exporting it to `docker images`. `buildx` makes
 this step configurable allowing results to be exported directly to the client,
-oci image tarballs, registry etc.
+OCI image tarballs, registry etc.
 
 Buildx with `docker` driver currently only supports local, tarball exporter and
 image exporter. `docker-container` driver supports all the exporters.
@@ -363,15 +359,15 @@ The `docker` export type writes the single-platform result image as a [Docker im
 specification](https://github.com/docker/docker/blob/v20.10.2/image/spec/v1.2.md)
 tarball on the client. Tarballs created by this exporter are also OCI compatible.
 
-Currently, multi-platform images cannot be exported with the `docker` export type.
+The default image store in Docker Engine doesn't support loading multi-platform
-The most common usecase for multi-platform images is to directly push to a registry
+images. You can enable the containerd image store, or push multi-platform images
-(see [`registry`](#registry)).
+is to directly push to a registry, see [`registry`](#registry).
 
 Attribute keys:
 
-- `dest` - destination path where tarball will be written. If not specified the
+- `dest` - destination path where tarball will be written. If not specified,
-  tar will be loaded automatically to the current docker instance.
+  the tar will be loaded automatically to the local image store.
-- `context` - name for the docker context where to import the result
+- `context` - name for the Docker context where to import the result
 
 #### `image`
 
@@ -382,7 +378,7 @@ can be automatically pushed to a registry by specifying attributes.
 Attribute keys:
 
 - `name` - name (references) for the new image.
-- `push` - boolean to automatically push the image.
+- `push` - Boolean to automatically push the image.
 
 #### `registry`
 
@@ -390,7 +386,7 @@ The `registry` exporter is a shortcut for `type=image,push=true`.
 
 ### <a name="platform"></a> Set the target platforms for the build (--platform)
 
-```
+```text
 --platform=value[,value]
 ```
 
@@ -419,12 +415,12 @@ and `arm` architectures. You can see what runtime platforms your current builder
 instance supports by running `docker buildx inspect --bootstrap`.
 
 Inside a `Dockerfile`, you can access the current platform value through
-`TARGETPLATFORM` build argument. Please refer to the [`docker build`
+`TARGETPLATFORM` build argument. Refer to the [`docker build`
 documentation](https://docs.docker.com/engine/reference/builder/#automatic-platform-args-in-the-global-scope)
 for the full description of automatic platform argument variants .
 
-The formatting for the platform specifier is defined in the [containerd source
+You can find the formatting definition for the platform specifier in the
-code](https://github.com/containerd/containerd/blob/v1.4.3/platforms/platforms.go#L63).
+[containerd source code](https://github.com/containerd/containerd/blob/v1.4.3/platforms/platforms.go#L63).
 
 ```console
 $ docker buildx build --platform=linux/arm64 .
@@ -434,11 +430,11 @@ $ docker buildx build --platform=darwin .
 
 ### <a name="progress"></a> Set type of progress output (--progress)
 
-```
+```text
 --progress=VALUE
 ```
 
-Set type of progress output (auto, plain, tty). Use plain to show container
+Set type of progress output (`auto`, `plain`, `tty`). Use plain to show container
 output (default "auto").
 
 > **Note**
@@ -472,15 +468,18 @@ provenance attestations for the build result. For example,
 `--provenance=mode=max` can be used as an abbreviation for
 `--attest=type=provenance,mode=max`.
 
-Additionally, `--provenance` can be used with boolean values to broadly enable
+Additionally, `--provenance` can be used with Boolean values to enable or disable
-or disable provenance attestations. For example, `--provenance=false` can be
+provenance attestations. For example, `--provenance=false` disables all provenance attestations,
-used to disable all provenance attestations, while `--provenance=true` can be
+while `--provenance=true` enables all provenance attestations.
-used to enable all provenance attestations.
 
 By default, a minimal provenance attestation will be created for the build
-result, which will only be attached for images pushed to registries.
+result. Note that the default image store in Docker Engine doesn't support
+attestations. Provenance attestations only persist for images pushed directly
+to a registry if you use the default image store. Alternatively, you can switch
+to using the containerd image store.
 
-For more information, see [here](https://docs.docker.com/build/attestations/slsa-provenance/).
+For more information about provenance attestations, see
+[here](https://docs.docker.com/build/attestations/slsa-provenance/).
 
 ### <a name="push"></a> Push the build result to a registry (--push)
 
@@ -494,15 +493,19 @@ attestations for the build result. For example,
 `--sbom=generator=<user>/<generator-image>` can be used as an abbreviation for
 `--attest=type=sbom,generator=<user>/<generator-image>`.
 
-Additionally, `--sbom` can be used with boolean values to broadly enable or
+Additionally, `--sbom` can be used with Boolean values to enable or disable
-disable SBOM attestations. For example, `--sbom=false` can be used to disable
+SBOM attestations. For example, `--sbom=false` disables all SBOM attestations.
-all SBOM attestations.
+
+Note that the default image store in Docker Engine doesn't support
+attestations. Provenance attestations only persist for images pushed directly
+to a registry if you use the default image store. Alternatively, you can switch
+to using the containerd image store.
 
 For more information, see [here](https://docs.docker.com/build/attestations/sbom/).
 
 ### <a name="secret"></a> Secret to expose to the build (--secret)
 
-```
+```text
 --secret=[type=TYPE[,KEY=VALUE]
 ```
 
@@ -515,7 +518,7 @@ If `type` is unset it will be detected. Supported types are:
 
 Attribute keys:
 
-- `id` - ID of the secret. Defaults to basename of the `src` path.
+- `id` - ID of the secret. Defaults to base name of the `src` path.
 - `src`, `source` - Secret filename. `id` used if unset.
 
 ```dockerfile
@@ -557,7 +560,7 @@ optional and can be `b` (bytes), `k` (kilobytes), `m` (megabytes), or `g`
 
 ### <a name="ssh"></a> SSH agent socket or keys to expose to the build (--ssh)
 
-```
+```text
 --ssh=default|<id>[=<socket>|<key>[,<key>]]
 ```
 
@@ -597,6 +600,6 @@ $ docker buildx build --ulimit nofile=1024:1024 .
 
 > **Note**
 >
-> If you do not provide a `hard limit`, the `soft limit` is used
+> If you don't provide a `hard limit`, the `soft limit` is used
-> for both values. If no `ulimits` are set, they are inherited from
+> for both values. If no `ulimits` are set, they're inherited from
 > the default `ulimits` set on the daemon.

docs/reference/buildx_create.md

@@ -1,6 +1,6 @@
 # buildx create
 
-```
+```text
 docker buildx create [OPTIONS] [CONTEXT|ENDPOINT]
 ```
 
@@ -29,9 +29,9 @@ Create a new builder instance
 
 ## Description
 
-Create makes a new builder instance pointing to a docker context or endpoint,
+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).
+the address for Docker socket (eg. `DOCKER_HOST` value).
 
 By default, the current Docker configuration is used for determining the
 context/endpoint value.
@@ -57,7 +57,7 @@ eager_beaver
 
 ### <a name="buildkitd-flags"></a> Specify options for the buildkitd daemon (--buildkitd-flags)
 
-```
+```text
 --buildkitd-flags FLAGS
 ```
 
@@ -65,13 +65,13 @@ Adds flags when starting the buildkitd daemon. They take precedence over the
 configuration file specified by [`--config`](#config). See `buildkitd --help`
 for the available flags.
 
-```
+```text
 --buildkitd-flags '--debug --debugaddr 0.0.0.0:6666'
 ```
 
 ### <a name="config"></a> Specify a configuration file for the buildkitd daemon (--config)
 
-```
+```text
 --config FILE
 ```
 
@@ -79,7 +79,8 @@ Specifies the configuration file for the buildkitd daemon to use. The configurat
 can be overridden by [`--buildkitd-flags`](#buildkitd-flags).
 See an [example buildkitd configuration file](https://github.com/moby/buildkit/blob/master/docs/buildkitd.toml.md).
 
-If the configuration file is not specified, will look for one by default in:
+If you don't specify a configuration file, Buildx looks for one by default in:
+
 * `$BUILDX_CONFIG/buildkitd.default.toml`
 * `$DOCKER_CONFIG/buildx/buildkitd.default.toml`
 * `~/.docker/buildx/buildkitd.default.toml`
@@ -91,23 +92,30 @@ will be updated to reflect that.
 
 ### <a name="driver"></a> Set the builder driver to use (--driver)
 
-```
+```text
 --driver DRIVER
 ```
 
-Sets the builder driver to be used. There are two available drivers, each have
+Sets the builder driver to be used. A driver is a configuration of a BuildKit
-their own specificities.
+backend. Buildx supports the following drivers:
+
+* `docker` (default)
+* `docker-container`
+* `kubernetes`
+* `remote`
+
+For more information about build drivers, see [here](https://docs.docker.com/build/drivers/).
 
 #### `docker` driver
 
-Uses the builder that is built into the docker daemon. With this driver,
+Uses the builder that is built into the Docker daemon. With this driver,
 the [`--load`](buildx_build.md#load) flag is implied by default on
 `buildx build`. However, building multi-platform images or exporting cache is
 not currently supported.
 
 #### `docker-container` driver
 
-Uses a BuildKit container that will be spawned via docker. With this driver,
+Uses a BuildKit container that will be spawned via Docker. With this driver,
 both building multi-platform images and exporting cache are supported.
 
 Unlike `docker` driver, built images will not automatically appear in
@@ -116,7 +124,7 @@ to achieve that.
 
 #### `kubernetes` driver
 
-Uses a kubernetes pods. With this driver, you can spin up pods with defined
+Uses Kubernetes pods. With this driver, you can spin up pods with defined
 BuildKit container image to build your images.
 
 Unlike `docker` driver, built images will not automatically appear in
@@ -135,59 +143,18 @@ to achieve that.
 
 ### <a name="driver-opt"></a> Set additional driver-specific options (--driver-opt)
 
-```
+```text
 --driver-opt OPTIONS
 ```
 
 Passes additional driver-specific options.
+For information about available driver options, refer to the detailed
+documentation for the specific driver:
 
-Note: When using quoted values for the `nodeselector`, `annotations`, `labels` or
+* [`docker` driver](https://docs.docker.com/build/drivers/docker/)
-`tolerations` options, ensure that quotes are escaped correctly for your shell.
+* [`docker-container` driver](https://docs.docker.com/build/drivers/docker-container/)
-
+* [`kubernetes` driver](https://docs.docker.com/build/drivers/kubernetes/)
-#### `docker` driver
+* [`remote` driver](https://docs.docker.com/build/drivers/remote/)
-
-No driver options.
-
-#### `docker-container` driver
-
-- `image=IMAGE` - Sets the BuildKit image to use for the container.
-- `memory=MEMORY` - Sets the amount of memory the container can use.
-- `memory-swap=MEMORY_SWAP` - Sets the memory swap limit for the container.
-- `cpu-quota=CPU_QUOTA` - Imposes a CPU CFS quota on the container.
-- `cpu-period=CPU_PERIOD` - Sets the CPU CFS scheduler period for the container.
-- `cpu-shares=CPU_SHARES` - Configures CPU shares (relative weight) of the container.
-- `cpuset-cpus=CPUSET_CPUS` - Limits the set of CPU cores the container can use.
-- `cpuset-mems=CPUSET_MEMS` - Limits the set of CPU memory nodes the container can use.
-- `network=NETMODE` - Sets the network mode for the container.
-- `cgroup-parent=CGROUP` - Sets the cgroup parent of the container if docker is using the "cgroupfs" driver. Defaults to `/docker/buildx`.
-
-Before you configure the resource limits for the container, read about [configuring runtime resource constraints for containers](https://docs.docker.com/config/containers/resource_constraints/).
-
-#### `kubernetes` driver
-
-- `image=IMAGE` - Sets the container image to be used for running buildkit.
-- `namespace=NS` - Sets the Kubernetes namespace. Defaults to the current namespace.
-- `replicas=N` - Sets the number of `Pod` replicas. Defaults to 1.
-- `requests.cpu` - Sets the request CPU value specified in units of Kubernetes CPU. Example `requests.cpu=100m`, `requests.cpu=2`
-- `requests.memory` - Sets the request memory value specified in bytes or with a valid suffix. Example `requests.memory=500Mi`, `requests.memory=4G`
-- `limits.cpu` - Sets the limit CPU value specified in units of Kubernetes CPU. Example `limits.cpu=100m`, `limits.cpu=2`
-- `limits.memory` - Sets the limit memory value specified in bytes or with a valid suffix. Example `limits.memory=500Mi`, `limits.memory=4G`
-- `serviceaccount` - Sets the created pod's service account. Example `serviceaccount=example-sa`
-- `"nodeselector=label1=value1,label2=value2"` - Sets the kv of `Pod` nodeSelector. No Defaults. Example `nodeselector=kubernetes.io/arch=arm64`
-- `"annotations=domain/thing1=value1,domain/thing2=value2"` - Sets additional annotations on the deployments and pods. No Defaults. Example `annotations=example.com/owner=sarah`
-- `"labels=domain/thing1=value1,domain/thing2=value2"` - Sets additional labels on the deployments and pods. No Defaults. Example `labels=example.com/team=rd`
-- `"tolerations=key=foo,value=bar;key=foo2,operator=exists;key=foo3,effect=NoSchedule"` - Sets the `Pod` tolerations. Accepts the same values as the kube manifest tolera>tions. Key-value pairs are separated by `,`, tolerations are separated by `;`. No Defaults. Example `tolerations=operator=exists`
-- `rootless=(true|false)` - Run the container as a non-root user without `securityContext.privileged`. Needs Kubernetes 1.19 or later. [Using Ubuntu host kernel is recommended](https://github.com/moby/buildkit/blob/master/docs/rootless.md). Defaults to false.
-- `loadbalance=(sticky|random)` - Load-balancing strategy. If set to "sticky", the pod is chosen using the hash of the context path. Defaults to "sticky"
-- `qemu.install=(true|false)` - Install QEMU emulation for multi platforms support.
-- `qemu.image=IMAGE` - Sets the QEMU emulation image. Defaults to `tonistiigi/binfmt:latest`
-
-#### `remote` driver
-
-- `key=KEY` - Sets the TLS client key.
-- `cert=CERT` - Sets the TLS client certificate to present to buildkitd.
-- `cacert=CACERT` - Sets the TLS certificate authority used for validation.
-- `servername=SERVER` - Sets the TLS server name to be used in requests (defaults to the endpoint hostname).
 
 ### <a name="leave"></a> Remove a node from a builder (--leave)
 
@@ -201,7 +168,7 @@ $ docker buildx create --name mybuilder --node mybuilder0 --leave
 
 ### <a name="name"></a> Specify the name of the builder (--name)
 
-```
+```text
 --name NAME
 ```
 
@@ -210,17 +177,17 @@ If none is specified, one will be automatically generated.
 
 ### <a name="node"></a> Specify the name of the node (--node)
 
-```
+```text
 --node NODE
 ```
 
 The `--node` flag specifies the name of the node to be created or modified. If
-none is specified, it is the name of the builder it belongs to, with an index
+you don't specify a name, the node name defaults to the name of the builder it
-number suffix.
+belongs to, with an index number suffix.
 
 ### <a name="platform"></a> Set the platforms supported by the node (--platform)
 
-```
+```text
 --platform PLATFORMS
 ```
 

docs/reference/buildx_du.md

@@ -1,6 +1,6 @@
 # buildx du
 
-```
+```text
 docker buildx du
 ```
 

docs/reference/buildx_imagetools.md

@@ -1,6 +1,6 @@
 # buildx imagetools
 
-```
+```text
 docker buildx imagetools [OPTIONS] COMMAND
 ```
 
@@ -26,8 +26,9 @@ Commands to work on images in registry
 
 ## Description
 
-Imagetools contains commands for working with manifest lists in the registry.
+The `imagetools` commands contains subcommands for working with manifest lists
-These commands are useful for inspecting multi-platform build results.
+in container registries. These commands are useful for inspecting manifests
+to check multi-platform configuration and attestations.
 
 ## Examples
 

docs/reference/buildx_imagetools_create.md

@@ -1,6 +1,6 @@
 # buildx imagetools create
 
-```
+```text
 docker buildx imagetools create [OPTIONS] [SOURCE] [SOURCE...]
 ```
 

docs/reference/buildx_imagetools_inspect.md

@@ -1,6 +1,6 @@
 # buildx imagetools inspect
 
-```
+```text
 docker buildx imagetools inspect [OPTIONS] NAME
 ```
 
@@ -123,12 +123,13 @@ Manifests:
 
 #### JSON output
 
-A `json` go template func is also available if you want to render fields as
+A `json` template function is also available if you want to render fields in
-JSON bytes:
+JSON format:
 
 ```console
 $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Manifest}}"
 ```
+
 ```json
 {
   "schemaVersion": 2,
@@ -165,6 +166,7 @@ $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Ma
 ```console
 $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Image}}"
 ```
+
 ```json
 {
   "created": "2022-12-01T11:46:47.713777178Z",
@@ -207,6 +209,7 @@ $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Im
 ```console
 $ docker buildx imagetools inspect moby/buildkit:master --format "{{json .Manifest}}"
 ```
+
 ```json
 {
   "schemaVersion": 2,
@@ -357,6 +360,7 @@ JSON output:
 ```console
 $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .Provenance}}"
 ```
+
 ```json
 {
   "SLSA": {
@@ -417,6 +421,7 @@ JSON output:
 ```console
 $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .SBOM}}"
 ```
+
 ```json
 {
   "SPDX": {
@@ -441,6 +446,7 @@ $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .SB
 ```console
 $ docker buildx imagetools inspect crazymax/buildkit:attest --format "{{json .}}"
 ```
+
 ```json
 {
   "name": "crazymax/buildkit:attest",
@@ -522,6 +528,7 @@ go template function:
 ```console
 $ docker buildx imagetools inspect --format '{{json (index .Image "linux/s390x")}}' moby/buildkit:master
 ```
+
 ```json
 {
   "created": "2022-11-30T17:42:26.414957336Z",
@@ -588,15 +595,14 @@ $ docker buildx imagetools inspect --format '{{json (index .Image "linux/s390x")
 }
 ```
 
-### <a name="raw"></a> Show original, unformatted JSON manifest (--raw)
+### <a name="raw"></a> Show original JSON manifest (--raw)
 
-Use the `--raw` option to print the unformatted JSON manifest bytes.
+Use the `--raw` option to print the raw JSON manifest.
-
-> `jq` is used here to get a better rendering of the output result.
 
 ```console
-$ docker buildx imagetools inspect --raw crazymax/loop | jq
+$ docker buildx imagetools inspect --raw crazymax/loop
 ```
+
 ```json
 {
   "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
@@ -629,6 +635,7 @@ $ docker buildx imagetools inspect --raw crazymax/loop | jq
 ```console
 $ docker buildx imagetools inspect --raw moby/buildkit:master | jq
 ```
+
 ```json
 {
   "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",

docs/reference/buildx_inspect.md

@@ -1,6 +1,6 @@
 # buildx inspect
 
-```
+```text
 docker buildx inspect [NAME]
 ```
 
@@ -27,7 +27,7 @@ Shows information about the current or specified builder.
 
 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
+the BuildKit container and waits until it's operational. Bootstrapping is
 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`).
@@ -45,7 +45,9 @@ The following example shows information about a builder instance named
 
 > **Note**
 >
-> Asterisk `*` next to node build platform(s) indicate they had been set manually during `buildx create`. Otherwise, it had been autodetected.
+> The asterisk (`*`) next to node build platform(s) indicate they have been
+> manually set during `buildx create`. Otherwise the platforms were
+> automatically detected.
 
 ```console
 $ docker buildx inspect elated_tesla

docs/reference/buildx_ls.md

@@ -1,6 +1,6 @@
 # buildx ls
 
-```
+```text
 docker buildx ls
 ```
 

docs/reference/buildx_prune.md

@@ -1,6 +1,6 @@
 # buildx prune
 
-```
+```text
 docker buildx prune
 ```
 

docs/reference/buildx_rm.md

@@ -1,6 +1,6 @@
 # buildx rm
 
-```
+```text
 docker buildx rm [NAME]
 ```
 
@@ -50,10 +50,13 @@ $ docker buildx rm --all-inactive --force
 
 ### <a name="keep-daemon"></a> Keep the buildkitd daemon running (--keep-daemon)
 
-Keep the buildkitd daemon running after the buildx context is removed. This is useful when you manage buildkitd daemons and buildx contexts independently.
+Keep the BuildKit daemon running after the buildx context is removed. This is
-Currently, only supported by the [`docker-container` and `kubernetes` drivers](buildx_create.md#driver).
+useful when you manage buildkitd daemons and buildx contexts independently.
+Only supported by the
+[`docker-container`](https://docs.docker.com/build/drivers/docker-container/)
+and [`kubernetes`](https://docs.docker.com/build/drivers/kubernetes/) drivers.
 
 ### <a name="keep-state"></a> Keep BuildKit state (--keep-state)
 
 Keep BuildKit state, so it can be reused by a new builder with the same name.
-Currently, only supported by the [`docker-container` driver](buildx_create.md#driver).
+Currently, only supported by the [`docker-container` driver](https://docs.docker.com/build/drivers/docker-container/).

docs/reference/buildx_stop.md

@@ -18,7 +18,7 @@ Stop builder instance
 
 ## Description
 
-Stops the specified or current builder. This will not prevent buildx build to
+Stops the specified or current builder. This does not prevent buildx build to
 restart the builder. The implementation of stop depends on the driver.
 
 ## Examples

docs/reference/buildx_version.md

@@ -1,6 +1,6 @@
 # buildx version
 
-```
+```text
 docker buildx version
 ```
 
@@ -16,5 +16,5 @@ View version information
 
 ```console
 $ docker buildx version
-github.com/docker/buildx v0.5.1-docker 11057da37336192bfc57d81e02359ba7ba848e4a
+github.com/docker/buildx v0.11.2 9872040b6626fb7d87ef7296fd5b832e8cc2ad17
 ```