This is a follow-up to 7609dde8d0 and
3f5b1bdd32, which removed support for
DCT for build and plugin commands.
As these flags are just stubs, hidden by default and no longer functional,
they don't have to reflect the current state of DCT.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's adding a slight indirection by constructing a function when called,
but makes the completion functions more consistent, the signature easier
to read, and making the return type a [cobra.CompletionFunc] makes it
more transparent what it's intended for, and helps discovery of functions
that provide completion.
[cobra.CompletionFunc]: https://pkg.go.dev/github.com/spf13/cobra#CompletionFunc
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This warning was added in [moby@4a8b3ca] to print a warning when building
Linux images from a Windows client. Window's filesystem does not have an
"executable" bit, which mean that, for example, copying a shell script
to an image during build would lose the executable bit. So for Windows
clients, the executable bit would be set on all files, unconditionally.
Originally this was detected in the client, which had direct access to
the API response headers, but when refactoring the client to use a common
library in [moby@535c4c9], this was refactored into a `ImageBuildResponse`
wrapper, deconstructing the API response into an `io.Reader` and a string
field containing only the `OSType` header.
This was the only use and only purpose of the `OSType` field, and now that
BuildKit is the default builder for Linux images, this warning didn't get
printed unless BuildKit was explicitly disabled.
This patch removes the warning, so that we can potentially remove the
field, or the `ImageBuildResponse` type altogether.
[moby@4a8b3ca]: 4a8b3cad60
[moby@535c4c9]: 535c4c9a59
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
With this patch, completion is provided for images already present
in the local image cache to help pulling the latest version of the
same tag;
docker pull go<tab>
golang:1.12 golang:1.18.0 golang:1.21 golang:1.24 gopher:latest
golang:1.13 golang:1.20 golang:1.23 golang:latest
docker pull golang:<tab>
1.12 1.13 1.18.0 1.20 1.21 1.23 1.24 latest
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This replaces the visitAll recursive function with a test that verifies that
the option is set for all commands and subcommands, so that it doesn't have
to be modified at runtime.
We currently still have to loop over all functions for the setValidateArgs
call, but that can be looked at separately.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This special handling was added in [moby@9b6dcc8], and later updated in
[moby@c127d96], but it fully depended on string-matching, which is brittle.
Testing the original ticket that lead to this handling, it looks like the
string matching no longer works, and the daemon error is returned as-is:
With graphdrivers:
docker pull tiborvass/no-remove
Using default tag: latest
Error response from daemon: Encountered remote "application/vnd.docker.plugin.v0+json"(unknown) when fetching
With containerd snapshotters enabled:
docker pull tiborvass/no-remove
Using default tag: latest
latest: Pulling from tiborvass/no-remove
cf635291f7c9: Download complete
failed to unpack image on snapshotter overlayfs: mismatched image rootfs and manifest layers
The error-message for containerd can probably be improved, but as the special
handling in the CLI no longer works, we can remove it.
[moby@9b6dcc8]: 9b6dcc8b9d
[moby@c127d96]: c127d9614f
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used to share it between "trust" and "image",
but was only a shallow wrapper, so split the implementations where
used.
It was deprecated in 7ad113ccc2 and is
no longer used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- Remove redundant intermediate variables
- Explicitly use an early return on error instead of combining with
other checks.
- Fix unhandled errors and combine defers
- Remove outstanding TODO that unlikely will be addressed
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was exported to share it between "trust" and "image",
but was only a shallow wrapper, so split the implementations where
used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These were exported in 812f113685, but
while the function and options are exported, the option-fields were
all un-exported, so these were not usable.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's part of the presentation logic of the cli, and only used internally.
We can consider providing utilities for these, but better as part of
separate packages.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch removes the explicit `commands.AddCommands` function and
instead relies upon the `internal/commands` package which registers each
CLI command using `init()` instead.
Signed-off-by: Alano Terblanche <18033717+Benehiko@users.noreply.github.com>
It was only used internally and has no external users. It should not be
used for new uses, because it also adds a minimum API version constraint
and a default from env-var, which must be evaluated for each individual
use of such flags.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds a "dry-run" / "pre-check" option for prune-functions,
which delegates constructing the confirmation message (what is
about to be pruned) and validation of the given options to the
prune-functions.
This helps separating concerns, and doesn't enforce knowledge
about what's supported by each content-type onto the system
prune command.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Introduce a "prune" package in which we maintain a list of prune
functions that are registered. Known prune "content-types" are
included in a pre-defined order, after which additional content
can be registered.
Using this approach no longer requires the "RunPrune" functions
to be exported, and allows additional content-types to be
introduced without having to import those packages into the
system package, so keeping things more decoupled.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Most places only use IndexInfo (and may not even need that), so replace
the use of ParseRepositoryInfo for NewIndexInfo, and move the RepositoryInfo
type to the trust package, which uses it as part of its ImageRefAndAuth
struct.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Removed the error return from the `ParseRepositoryInfo` function.
There are no validation steps inside `ParseRepositoryInfo` which
could cause an error, so we always returned a nil error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We transitioned most functionality of docker/errdefs to containerd
errdefs module, and the docker/errdefs package should no longer be
used.
Because of that, there will no longer be ambiguity, so we can remove
the aliases for this package, and use it as "errdefs".
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This adds an internal fork of [github.com/docker/docker/registry], taken
at commit [moby@f651a5d]. Git history was not preserved in this fork,
but can be found using the URLs provided.
This fork was created to remove the dependency on the "Moby" codebase,
and because the CLI only needs a subset of its features. The original
package was written specifically for use in the daemon code, and includes
functionality that cannot be used in the CLI.
[github.com/docker/docker/registry]: https://pkg.go.dev/github.com/docker/docker@v28.3.2+incompatible/registry
[moby@49306c6]: 49306c607b/registry
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
Adds a local fork of this package for use in the classic builder.
Code was taken at commit [d33d46d01656e1d9ee26743f0c0d7779f685dd4e][1].
Migration was done using the following steps:
# install filter-repo (https://github.com/newren/git-filter-repo/blob/main/INSTALL.md)
brew install git-filter-repo
# create a temporary clone of docker
cd ~/Projects
git clone https://github.com/docker/docker.git build_context_temp
cd build_context_temp
# commit taken from
git rev-parse --verify HEAD
d33d46d01656e1d9ee26743f0c0d7779f685dd4e
git filter-repo --analyze
# remove all code, except for the remotecontext packages, and move to build/internal docs and previous locations of it
git filter-repo \
--path 'builder/remotecontext/git' \
--path 'builder/remotecontext/urlutil' \
--path-rename builder/remotecontext:cli/command/image/build/internal
# go to the target repository
cd ~/go/src/github.com/docker/cli
# create a branch to work with
git checkout -b fork_remotecontext
# add the temporary repository as an upstream and make sure it's up-to-date
git remote add build_context_temp ~/Projects/build_context_temp
git fetch build_context_temp
# merge the upstream code
git merge --allow-unrelated-histories --signoff -S build_context_temp/master
[1]: https://github.com/docker/docker/d33d46d01656e1d9ee26743f0c0d7779f685dd4e
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
