`go list` expects a module to be valid, which means that dependencies must
either be vendored, or downloaded in the module cache. However, when working
in GOPATH mode, `go.mod` files are ignored, which means that `go list` will
traverse subdirectories, even if those are a separate module, and those modules
may not have their dependencies present.
In our case, we try to exclude those modules from paths to be tested, but
do so based on the _result_ of `go list`, which already produces errors before
we filter.
These errors do not impact out tests, as we don't run tests for those paths,
but do produce noise in CI, which can be confusing;
go test -coverprofile=/tmp/coverage.txt $(go list ./... | grep -vE '/vendor/|/e2e/|/cmd/docker-trust')
cmd/docker-trust/internal/trust/trust.go:28:2: cannot find package "github.com/theupdateframework/notary" in any of:
/go/src/github.com/docker/cli/vendor/github.com/theupdateframework/notary (vendor tree)
/usr/local/go/src/github.com/theupdateframework/notary (from $GOROOT)
/go/src/github.com/theupdateframework/notary (from $GOPATH)
cmd/docker-trust/internal/trust/trust.go:29:2: cannot find package "github.com/theupdateframework/notary/client" in any of:
/go/src/github.com/docker/cli/vendor/github.com/theupdateframework/notary/client (vendor tree)
/usr/local/go/src/github.com/theupdateframework/notary/client (from $GOROOT)
/go/src/github.com/theupdateframework/notary/client (from $GOPATH)
This patch adds a symlink for `go.mod` and `go.sum`, so that listing the
packages happens in go modules mode, and doesn't traverse to other modules,
such as `cmd/docker-trust`.
- updates 06914dd0ff, which attempted to
exclude the docker-trust plugin
- similar to cee9ea67fc, which made this
change for the linter.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This was introduced in 9c10a9c9ac, which added
use of the network.ParsePortRange.All method, which uses an iterator and
requires go1.23;
opts/swarmopts/port.go:172:18: cannot range over pr.All() (value of func type iter.Seq[network.Port]): requires go1.23 or later (-lang was set to go1.16; check go.mod)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 4d3a76d71e updated the list of directories
for discovering CLI plugins, adding `%ProgramFiles%\Docker\cli-plugins` for
system-wide plugins.
For backward compatibility, the `%PROGRAMDATA%\Docker\cli-plugins` was kept,
however, this location is no longer used, and not generally recommended for
storing non-data content (such as CLI plugin binaries). From the [ProgramData]
documentation:
> ProgramData specifies the path to the program-data folder (normally C:\ProgramData).
> Unlike the Program Files folder, this folder can be used by applications to store
> data for standard users, because it does not require elevated permissions.
It also mentions "It can’t contain any serviceable components.", effectively
meaning that these paths should not contain data that is managed (through
updates etc.), making it a poor choice for installing "system wide" CLI plugins.
This patch removes the path from the list, given that this location is no longer
used by Docker Desktop, and the CLI-plugin API is considered an internal
implementation (since 459c6082f8).
[ProgramData]: https://learn.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-folderlocations-programdata
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The --all flag description was misleading by only mentioning
intermediate images, when it actually also controls the visibility of
dangling (untagged) images.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This reverts part of the logic introduced in 207bf52c27 which
incorrectly gated untagged images behind the --all flag in non-expanded
view.
The original fix was addressing the wrong layer of the problem.
The actual issue was that dangling images were being incorrectly passed
to the tree code in the first place.
This was properly fixed in 67f5e3413 which corrected the dangling image
detection logic to properly filter them out before reaching the tree
display code.
Now that dangling images are correctly filtered upstream, untagged
images that reach the tree view should be displayed regardless of the
--all flag setting.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
When calculating column widths for the tree view, untagged images
weren't being properly accounted for in the width calculation.
This caused layout issues when there were tagged images were shorter
than the `<untagged>` string.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
The isDangling function was incorrectly identifying images as dangling
when they had no RepoTags but had valid RepoDigests.
This can occur when the graphdrivers are used instead of the containerd
image store.
An image should only be considered dangling if it has no RepoTags,
regardless of whether it has RepoDigests.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
