Merge pull request #2659 from dvdksn/docs-alerts-syntax

docs: use gh alert syntax for callouts

README.md

@@ -56,8 +56,7 @@ For more information on how to use Buildx, see
 
 Using `buildx` with Docker requires Docker engine 19.03 or newer.
 
-> **Warning**
+> [!WARNING]
->
 > Using an incompatible version of Docker may result in unexpected behavior,
 > and will likely cause issues, especially when using Buildx builders with more
 > recent versions of BuildKit.
@@ -75,8 +74,7 @@ Docker Engine package repositories contain Docker Buildx packages when installed
 
 ## Manual download
 
-> **Important**
+> [!IMPORTANT]
->
 > This section is for unattended installation of the buildx component. These
 > instructions are mostly suitable for testing purposes. We do not recommend
 > installing buildx using manual download in production environments as they
@@ -107,8 +105,7 @@ On Windows:
 * `C:\ProgramData\Docker\cli-plugins`
 * `C:\Program Files\Docker\cli-plugins`
 
-> **Note**
+> [!NOTE]
->
 > On Unix environments, it may also be necessary to make it executable with `chmod +x`:
 > ```shell
 > $ chmod +x ~/.docker/cli-plugins/docker-buildx

docs/bake-reference.md

@@ -443,8 +443,7 @@ COPY --from=src . .
 
 #### Use another target as base
 
-> **Note**
+> [!NOTE]
->
 > You should prefer to use regular multi-stage builds over this option. You can
 > Use this feature when you have multiple Dockerfiles that can't be easily
 > merged into one.
@@ -853,8 +852,7 @@ target "default" {
 }
 ```
 
-> **Note**
+> [!NOTE]
->
 > In most cases, it is recommended to let the builder automatically determine
 > the appropriate configurations. Manual adjustments should only be considered
 > when specific performance tuning is required for complex build scenarios.
@@ -919,14 +917,12 @@ target "app" {
 }
 ```
 
-> **Note**
+> [!NOTE]
->
 > If you do not provide a `hard limit`, the `soft limit` is used
 > for both values. If no `ulimits` are set, they are inherited from
 > the default `ulimits` set on the daemon.
 
-> **Note**
+> [!NOTE]
->
 > In most cases, it is recommended to let the builder automatically determine
 > the appropriate configurations. Manual adjustments should only be considered
 > when specific performance tuning is required for complex build scenarios.
@@ -1114,8 +1110,7 @@ target "webapp-dev" {
 }
 ```
 
-> **Note**
+> [!NOTE]
->
 > See [User defined HCL functions][hcl-funcs] page for more details.
 
 <!-- external links -->

docs/debugging.md

@@ -4,8 +4,7 @@ To assist with creating and debugging complex builds, Buildx provides a
 debugger to help you step through the build process and easily inspect the
 state of the build environment at any point.
 
-> **Note**
+> [!NOTE]
->
 > The debug monitor is a new experimental feature in recent versions of Buildx.
 > There are rough edges, known bugs, and missing features. Please try it out
 > and let us know what you think!

docs/reference/buildx_bake.md

@@ -41,8 +41,7 @@ as part of the build.
 Read [High-level build options with Bake](https://docs.docker.com/build/bake/)
 guide for introduction to writing bake files.
 
-> **Note**
+> [!NOTE]
->
 > `buildx bake` command may receive backwards incompatible features in the future
 > if needed. We are looking for feedback on improving the command and extending
 > the functionality further.
@@ -163,8 +162,7 @@ $ cat metadata.json
 }
 ```
 
-> **Note**
+> [!NOTE]
->
 > Build record [provenance](https://docs.docker.com/build/attestations/slsa-provenance/#provenance-attestation-example)
 > (`buildx.build.provenance`) includes minimal provenance by default. Set the
 > `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior:
@@ -172,8 +170,7 @@ $ cat metadata.json
 > * `max` sets full provenance.
 > * `disabled`, `false` or `0` does not set any provenance.
 
-> **Note**
+> [!NOTE]
-> 
 > Build warnings (`buildx.build.warnings`) are not included by default. Set the
 > `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
 > include them.

docs/reference/buildx_build.md

@@ -581,8 +581,7 @@ $ cat metadata.json
 }
 ```
 
-> **Note**
+> [!NOTE]
->
 > Build record [provenance](https://docs.docker.com/build/attestations/slsa-provenance/#provenance-attestation-example)
 > (`buildx.build.provenance`) includes minimal provenance by default. Set the
 > `BUILDX_METADATA_PROVENANCE` environment variable to customize this behavior:
@@ -591,8 +590,7 @@ $ cat metadata.json
 > - `max` sets full provenance.
 > - `disabled`, `false` or `0` doesn't set any provenance.
 
-> **Note**
+> [!NOTE]
-> 
 > Build warnings (`buildx.build.warnings`) are not included by default. Set the
 > `BUILDX_METADATA_WARNINGS` environment variable to `1` or `true` to
 > include them.
@@ -832,8 +830,7 @@ $ docker buildx build --platform=darwin .
 Set type of progress output (`auto`, `plain`, `tty`, `rawjson`). Use `plain` to show container
 output (default `auto`).
 
-> **Note**
+> [!NOTE]
->
 > You can also use the `BUILDKIT_PROGRESS` environment variable to set its value.
 
 The following example uses `plain` output during the build:
@@ -851,8 +848,7 @@ $ docker buildx build --load --progress=plain .
 ...
 ```
 
-> **Note**
+> [!NOTE]
->
 > Check also the [`BUILDKIT_COLORS`](https://docs.docker.com/build/building/variables/#buildkit_colors)
 > environment variable for modifying the colors of the terminal output.
 
@@ -967,8 +963,7 @@ The format is `<number><unit>`. `number` must be greater than `0`. Unit is
 optional and can be `b` (bytes), `k` (kilobytes), `m` (megabytes), or `g`
 (gigabytes). If you omit the unit, the system uses bytes.
 
-> **Note**
+> [!NOTE]
->
 > In most cases, it is recommended to let the builder automatically determine
 > the appropriate configurations. Manual adjustments should only be considered
 > when specific performance tuning is required for complex build scenarios.
@@ -1054,14 +1049,12 @@ instructions and are specified with a soft and hard limit as such:
 $ docker buildx build --ulimit nofile=1024:1024 .
 ```
 
-> **Note**
+> [!NOTE]
->
 > If you don't provide a `hard limit`, the `soft limit` is used
 > for both values. If no `ulimits` are set, they're inherited from
 > the default `ulimits` set on the daemon.
 
-> **Note**
+> [!NOTE]
->
 > In most cases, it is recommended to let the builder automatically determine
 > the appropriate configurations. Manual adjustments should only be considered
 > when specific performance tuning is required for complex build scenarios.

docs/reference/buildx_create.md

@@ -101,8 +101,7 @@ value is `auto` and can be one of `bridge`, `cni`, `host`:
 --buildkitd-flags '--oci-worker-net bridge'
 ```
 
-> **Note**
+> [!NOTE]
->
 > Network mode "bridge" is supported since BuildKit v0.13 and will become the
 > default in next v0.14.
 

docs/reference/buildx_imagetools_create.md

@@ -52,8 +52,7 @@ $ docker buildx imagetools create \
   foo/bar:alpha foo/bar:beta foo/bar:gamma
 ```
 
-> **Note**
+> [!NOTE]
->
 > The `imagetools create` command supports adding annotations to the image
 > index and descriptor, using the following type prefixes:
 >

docs/reference/buildx_inspect.md

@@ -43,8 +43,7 @@ name of the builder to inspect to get information about that builder.
 The following example shows information about a builder instance named
 `elated_tesla`:
 
-> **Note**
+> [!NOTE]
->
 > The asterisk (`*`) next to node build platform(s) indicate they have been
 > manually set during `buildx create`. Otherwise the platforms were
 > automatically detected.