Merge pull request #17902 from dvdksn/build/golinks-clierrmsg

build: add redirects for cli error messages

_redirects.yml

@@ -596,3 +596,9 @@
   - /go/builders/selected/
 "https://www.docker.com/build-early-access-program/?utm_campaign=onboard-30-customer-zero&utm_medium=in-product-ad&utm_source=desktop_v4":
   - /go/build-eap/
+"/build/building/multi-platform/":
+  - /go/build-multi-platform/
+"/build/cache/backends/":
+  - /go/build-cache-backends/
+"/build/exporters/":
+  - /go/build-exporters/

build/cache/backends/index.md

@@ -13,6 +13,10 @@ An external cache becomes almost essential in CI/CD build environments. Such
 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.
 
+The default `docker` driver only supports embedded cache, using the `inline`
+cache type. To use external cache, you must select an alternative
+[build driver](../../drivers/index.md).
+
 > **Warning**
 >
 > If you use secrets or credentials inside your build process, ensure you
@@ -53,9 +57,7 @@ to export the cache to your storage backend of choice. Then, use the
 [`--cache-from` option](../../../engine/reference/commandline/buildx_build/#cache-from)
 to import the cache from the storage backend into the current build. Unlike the
 local BuildKit cache (which is always enabled), all of the cache storage
-backends must be explicitly exported to, and explicitly imported from. All cache
+backends must be explicitly exported to, and explicitly imported from.
-exporters except for the `inline` cache requires that you
-[select an alternative Buildx driver](../../drivers/index.md).
 
 Example `buildx` command using the `registry` backend, using import and export
 cache:

build/cache/backends/inline.md

@@ -7,11 +7,14 @@ redirect_from:
 
 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
-image. However, it doesn't scale as well to multi-stage builds as well as the
+image. Inline cache is the only cache backend supported by the default `docker`
-other drivers do. It also doesn't offer separation between your output artifacts
+driver.
-and your cache output. This means that if you're using a particularly complex
+
-build flow, or not exporting your images directly to a registry, then you may
+The downside of inline cache is that it doesn't scale with multi-stage builds
-want to consider the [registry](./registry.md) cache.
+as well as the other drivers do. It also doesn't offer separation between your
+output artifacts and your cache output. This means that if you're using a
+particularly complex build flow, or not exporting your images directly to a
+registry, then you may want to consider the [registry](./registry.md) cache.
 
 ## Synopsis