Docker Content Trust is currently only implemented for the classic
builder, but is known to not work with multi-stage builds, and
requires rewriting the Dockerfile, which is brittle because the
Dockerfile syntax evolved with the introduction of BuildKit as
default builder.
Given that the classic builder is deprecated, and only used for
Windows images, which are not verified by content trust;
# docker pull --disable-content-trust=false mcr.microsoft.com/windows/servercore:ltsc2025
Error: remote trust data does not exist for mcr.microsoft.com/windows/servercore: mcr.microsoft.com does not have trust data for mcr.microsoft.com/windows/servercore
With content trust not implemented in BuildKit, and not implemented
in docker compose, this resulted in an inconsistent behavior.
This patch removes content-trust support for "docker build". As this
is a client-side feature, users who require this feature can still
use an older CLI to to start the build.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This snippet was added in [docker@38ec5d8][1]. The intent was to indicate
that an empty value is equivalent to passing "default" as value. However,
passing the `--isolation` flag _without a value_ (i.e., no `=` specified)
will fail in many cases, as any string after it will be parsed as value
(e.g. `docker run --isolation busybox` would consider `busybox` as value).
This patch removes these lines as they add more confusion than addressing.
[1]: 38ec5d86a3
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move common flag descriptions to the buildx build reference, and make
that page the canonical page in docs. Also rewrite some content in
image_build to make clear that this page is only for the legacy builder.
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Alias pages redirect to the canonical names, but these pages still
linked to the aliases, causing broken links when building the docs site.
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
This attempts to make it clearer that the --cgroup-parent option is only used
for the containers used during build. Instead of mentioning "build container",
I opted for using "RUN instructions" (to match the --network description),
although this may not be ideal (as it assumes the "Dockerfile" front-end, which
of course may not be the case).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
