chore(vale): build fixes (#23277)

Author: ArthurFlag

.vale.ini

@@ -13,6 +13,19 @@ Docker.Capitalization = NO
 Vale.Spelling = NO
 Vale.Terms = NO
 Docker.Capitalization = NO
+Docker.We = NO
+
+[content/manuals/build/buildkit/dockerfile-release-notes.md]
+Vale.Spelling = NO
+Vale.Terms = NO
+Docker.Capitalization = NO
+Docker.We = NO
+
+[content/manuals/*/release-notes.md]
+Vale.Spelling = NO
+Vale.Terms = NO
+Docker.Capitalization = NO
+Docker.We = NO
 
 [content/contribute/*.md]
 Vale.Spelling = NO

_vale/config/vocabularies/Docker/accept.txt

@@ -14,14 +14,15 @@ bootup
 Btrfs
 Bugsnag
 BuildKit
+buildkitd
 BusyBox
 CentOS
 Ceph
 cgroup
 Chrome
 Chrome DevTools
-Citrix
 CI/CD
+Citrix
 cli
 CLI
 CloudFront
@@ -39,7 +40,6 @@ denylist
 deprovisioning
 deserialization
 deserialize
-[Dd]ev
 Dev Environments?
 Dex
 displayName
@@ -59,6 +59,7 @@ Docker's
 Dockerfile
 dockerignore
 Dockerize
+Dockerized
 Dockerizing
 Entra
 EPERM
@@ -129,6 +130,7 @@ netfilter
 netlabel
 netlink
 Netplan
+Neovim
 NFSv\d
 Nginx
 npm
@@ -142,9 +144,10 @@ osquery
 osxfs
 OTel
 Paketo
+perl
 pgAdmin
-plist
 PKG
+plist
 Postgres
 PowerShell
 Python
@@ -173,8 +176,8 @@ subvolume
 Syft
 syntaxes
 Sysbox
-sysctls
 sysctl
+sysctls
 Sysdig
 systemd
 Testcontainers
@@ -184,8 +187,6 @@ Trivy
 Trixie
 Ubuntu
 ufw
-ui
-uid
 umask
 uncaptured
 Uncaptured
@@ -203,6 +204,7 @@ Windows
 windowsfilter
 WireMock
 workdir
+WORKDIR
 Xdebug
 youki
 Yubikey
@@ -219,6 +221,8 @@ Zsh
 [Cc]odenames?
 [Cc]ompose
 [Cc]onfigs
+[dD]eduplicate
+[Dd]ev
 [Dd]istroless
 [Ff]ilepaths?
 [Ff]iletypes?

content/manuals/build/bake/variables.md

@@ -2,7 +2,7 @@
 title: Variables in Bake
 linkTitle: Variables
 weight: 40
-description: 
+description:
 keywords: build, buildx, bake, buildkit, hcl, variables
 ---
 
@@ -93,7 +93,7 @@ range, or other condition, you can define custom validation rules using the
 `validation` block.
 
 In the following example, validation is used to enforce a numeric constraint on
-a variable value; the `PORT` variable must be 1024 or higher.
+a variable value; the `PORT` variable must be 1024 or greater.
 
 ```hcl {title=docker-bake.hcl}
 # Define a variable `PORT` with a default value and a validation rule
@@ -103,7 +103,7 @@ variable "PORT" {
   # Validation block to ensure `PORT` is a valid number within the acceptable range
   validation {
     condition = PORT >= 1024  # Ensure `PORT` is at least 1024
-    error_message = "The variable 'PORT' must be 1024 or higher."  # Error message for invalid values
+    error_message = "The variable 'PORT' must be 1024 or greater."  # Error message for invalid values
   }
 }
 ```

content/manuals/build/building/best-practices.md

@@ -259,8 +259,8 @@ to create an efficient and maintainable Dockerfile.
 
 > [!TIP]
 >
-> Want a better editing experience for Dockerfiles in VS Code?
-> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.
+> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code
+> see [Docker VS Code Extension](https://marketplace.visualstudio.com/items?itemName=docker.docker).
 
 ### FROM
 
@@ -487,7 +487,7 @@ service, such as Apache and Rails, you would run something like `CMD
 for any service-based image.
 
 In most other cases, `CMD` should be given an interactive shell, such as bash,
-python and perl. For example, `CMD ["perl", "-de0"]`, `CMD ["python"]`, or `CMD
+Python and perl. For example, `CMD ["perl", "-de0"]`, `CMD ["python"]`, or `CMD
 ["php", "-a"]`. Using this form means that when you execute something like
 `docker run -it python`, you’ll get dropped into a usable shell, ready to go.
 `CMD` should rarely be used in the manner of `CMD ["param", "param"]` in
@@ -556,7 +556,7 @@ $ docker run --rm test sh -c 'echo $ADMIN_USER'
 mark
 ```
 
-To prevent this, and really unset the environment variable, use a `RUN` command
+To prevent this and unset the environment variable, use a `RUN` command
 with shell commands, to set, use, and unset the variable all in a single layer.
 You can separate your commands with `;` or `&&`. If you use the second method,
 and one of the commands fails, the `docker build` also fails. This is usually a
@@ -763,7 +763,7 @@ RUN groupadd -r postgres && useradd --no-log-init -r -g postgres postgres
 > with a significantly large UID inside a Docker container can lead to disk
 > exhaustion because `/var/log/faillog` in the container layer is filled with
 > NULL (\0) characters. A workaround is to pass the `--no-log-init` flag to
-> useradd. The Debian/Ubuntu `adduser` wrapper does not support this flag.
+> `useradd`. The Debian/Ubuntu `adduser` wrapper does not support this flag.
 
 Avoid installing or using `sudo` as it has unpredictable TTY and
 signal-forwarding behavior that can cause problems. If you absolutely need
@@ -778,11 +778,11 @@ For more information about `USER`, see [Dockerfile reference for the USER instru
 ### WORKDIR
 
 For clarity and reliability, you should always use absolute paths for your
-`WORKDIR`. Also, you should use `WORKDIR` instead of  proliferating instructions
+`WORKDIR`. Also, you should use `WORKDIR` instead of proliferating instructions
 like `RUN cd … && do-something`, which are hard to read, troubleshoot, and
 maintain.
 
-For more information about `WORKDIR`, see [Dockerfile reference for the WORKDIR instruction](/reference/dockerfile.md#workdir).
+For more information about `WORKDIR`, see [Dockerfile reference for the `WORKDIR` instruction](/reference/dockerfile.md#workdir).
 
 ### ONBUILD
 
@@ -802,7 +802,7 @@ Dockerfile, as you can see in [Ruby’s `ONBUILD` variants](https://github.com/d
 Images built with `ONBUILD` should get a separate tag. For example,
 `ruby:1.9-onbuild` or `ruby:2.0-onbuild`.
 
-Be careful when putting `ADD` or `COPY` in `ONBUILD`. The onbuild image
+Be careful when putting `ADD` or `COPY` in `ONBUILD`. The `onbuild image
 fails catastrophically if the new build's context is missing the resource being
 added. Adding a separate tag, as recommended above, helps mitigate this by
 allowing the Dockerfile author to make a choice.

content/manuals/build/buildkit/_index.md

@@ -29,8 +29,9 @@ Apart from many new features, the main areas BuildKit improves on the current
 experience are performance, storage management, and extensibility. From the
 performance side, a significant update is a new fully concurrent build graph
 solver. It can run build steps in parallel when possible and optimize out
-commands that don't have an impact on the final result. We have also optimized
-the access to the local source files. By tracking only the updates made to these
+commands that don't have an impact on the final result.
+The access to the local source files has also been optimized. By tracking
+only the updates made to these
 files between repeated build invocations, there is no need to wait for local
 files to be read or uploaded before the work can begin.
 
@@ -39,7 +40,7 @@ files to be read or uploaded before the work can begin.
 At the core of BuildKit is a
 [Low-Level Build (LLB)](https://github.com/moby/buildkit#exploring-llb) definition format. LLB is an intermediate binary format
 that allows developers to extend BuildKit. LLB defines a content-addressable
-dependency graph that can be used to put together very complex build
+dependency graph that can be used to put together complex build
 definitions. It also supports features not exposed in Dockerfiles, like direct
 data mounting and nested invocation.
 
@@ -115,7 +116,7 @@ daemon.
 
 BuildKit has experimental support for Windows containers (WCOW) as of version 0.13.
 This section walks you through the steps for trying it out.
-We appreciate any feedback you submit by [opening an issue here](https://github.com/moby/buildkit/issues/new), especially `buildkitd.exe`.
+To share feedback, [open an issue in the repository](https://github.com/moby/buildkit/issues/new), especially `buildkitd.exe`.
 
 ### Known limitations
 

content/manuals/build/checks.md

@@ -38,8 +38,8 @@ Build checks are useful for:
 
 > [!TIP]
 >
-> Want a better editing experience for Dockerfiles in VS Code?
-> Check out the [Docker VS Code Extension (Beta)](https://marketplace.visualstudio.com/items?itemName=docker.docker) for linting, code navigation, and vulnerability scanning.
+> To improve linting, code navigation, and vulnerability scanning of your Dockerfiles in Visual Studio Code
+> see [Docker VS Code Extension](https://marketplace.visualstudio.com/items?itemName=docker.docker).
 
 ## Build with checks
 

content/manuals/build/ci/github-actions/_index.md

@@ -29,7 +29,7 @@ The following GitHub Actions are available:
 - [Docker Setup Compose](https://github.com/marketplace/actions/docker-setup-compose):
   installs and sets up [Compose](../../../compose).
 - [Docker Setup Docker](https://github.com/marketplace/actions/docker-setup-docker):
-  installs Docker CE.
+  installs Docker Engine.
 - [Docker Setup QEMU](https://github.com/marketplace/actions/docker-setup-qemu):
   installs [QEMU](https://github.com/qemu/qemu) static binaries for
   multi-platform builds.

content/manuals/build/ci/github-actions/cache.md

@@ -37,7 +37,7 @@ jobs:
 
       - name: Set up Docker Buildx
         uses: docker/setup-buildx-action@v3
-      
+
       - name: Build and push
         uses: docker/build-push-action@v6
         with:
@@ -67,10 +67,10 @@ jobs:
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-      
+
       - name: Set up Docker Buildx
         uses: docker/setup-buildx-action@v3
-      
+
       - name: Build and push
         uses: docker/build-push-action@v6
         with:
@@ -108,10 +108,10 @@ jobs:
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-      
+
       - name: Set up Docker Buildx
         uses: docker/setup-buildx-action@v3
-      
+
       - name: Build and push
         uses: docker/build-push-action@v6
         with:
@@ -124,47 +124,47 @@ jobs:
 > [!IMPORTANT]
 >
 > Starting [April 15th, 2025, only GitHub Cache service API v2 will be supported](https://gh.io/gha-cache-sunset).
-> 
+>
 > If you encounter the following error during your build:
-> 
+>
 > ```console
 > ERROR: failed to solve: This legacy service is shutting down, effective April 15, 2025. Migrate to the new service ASAP. For more information: https://gh.io/gha-cache-sunset
 > ```
-> 
+>
 > You're probably using outdated tools that only support the legacy GitHub
 > Cache service API v1. Here are the minimum versions you need to upgrade to
 > depending on your use case:
 > * Docker Buildx >= v0.21.0
 > * BuildKit >= v0.20.0
 > * Docker Compose >= v2.33.1
 > * Docker Engine >= v28.0.0 (if you're building using the Docker driver with containerd image store enabled)
-> 
+>
 > If you're building using the `docker/build-push-action` or `docker/bake-action`
 > actions on GitHub hosted runners, Docker Buildx and BuildKit are already up
 > to date but on self-hosted runners, you may need to update them yourself.
 > Alternatively, you can use the `docker/setup-buildx-action` action to install
 > the latest version of Docker Buildx:
-> 
+>
 > ```yaml
 > - name: Set up Docker Buildx
 >   uses: docker/setup-buildx-action@v3
 >   with:
 >    version: latest
 > ```
-> 
+>
 > If you're building using Docker Compose, you can use the
 > `docker/setup-compose-action` action:
-> 
+>
 > ```yaml
 > - name: Set up Docker Compose
 >   uses: docker/setup-compose-action@v1
 >   with:
 >    version: latest
 > ```
-> 
+>
 > If you're building using the Docker Engine with the containerd image store
 > enabled, you can use the `docker/setup-docker-action` action:
-> 
+>
 > ```yaml
 > -
 >   name: Set up Docker
@@ -182,7 +182,7 @@ jobs:
 ### Cache mounts
 
 BuildKit doesn't preserve cache mounts in the GitHub Actions cache by default.
-If you wish to put your cache mounts into GitHub Actions cache and reuse it
+To put your cache mounts into GitHub Actions cache and reuse it
 between builds, you can use a workaround provided by
 [`reproducible-containers/buildkit-cache-dance`](https://github.com/reproducible-containers/buildkit-cache-dance).
 
@@ -224,7 +224,7 @@ jobs:
         with:
           username: ${{ vars.DOCKERHUB_USERNAME }}
           password: ${{ secrets.DOCKERHUB_TOKEN }}
-      
+
       - name: Set up QEMU
         uses: docker/setup-qemu-action@v3
 

content/manuals/build/concepts/context.md

@@ -498,6 +498,7 @@ The following code snippet shows an example `.dockerignore` file.
 */*/temp*
 temp?
 ```
+<!-- vale off -->
 
 This file causes the following build behavior:
 
@@ -508,6 +509,8 @@ This file causes the following build behavior:
 | `*/*/temp*` | Exclude files and directories starting with `temp` from any subdirectory that is two levels below the root. For example, `/somedir/subdir/temporary.txt` is excluded.                                         |
 | `temp?`     | Exclude files and directories in the root directory whose names are a one-character extension of `temp`. For example, `/tempa` and `/tempb` are excluded.                                                     |
 
+<!-- vale on -->
+
 Matching is done using Go's
 [`filepath.Match` function](https://golang.org/pkg/path/filepath#Match) rules.
 A preprocessing step uses Go's