Use a more generic "clientOptions" field to store options to apply
when constructing the API client, instead of a dedicated field for
user-agent.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Changed the environment variables section description from:
"The following list of environment variables are supported by the `docker` command line:"
To:
"The following environment variables control the behavior of the `docker` command-line client:"
This makes it clearer that these variables control Docker's behavior, and uses the more precise term "command-line client" instead of "command line".
Signed-off-by: Andrew Hopp <andrew.hopp@me.com>
`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>
- trace: fix data race in RenderEvents
- http2, webdav, websocket: fix %q verb uses with wrong type
- http2: don't PING a responsive server when resetting a stream
- http2: support net/http.Transport.NewClientConn
full diff: https://github.com/golang/net/compare/v0.47.0...v0.48.0
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>
