Various dependencies, including "golang.org/x/.." started to update
the minimum required version,so we should follow suit for the next
release.
Note that the `//go:build` directives not necesserily have to be
updated, but it's good to keep them in sync until we have a go.mod
to control this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Some tests had to be skipped as there's some issues to address, and
some of the result-types cannot be mocked / stubbed.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The ResolveDefaultContext function was exported in [cli@f820766] to allow
(unit) testing, but did not document that it was only exported for this
purpose. The only external use of this function is in buildx, which uses
it in a unit test that can be implemented without this function.
This patch deprecates the function so that we can remove it.
[cli@f820766]: f820766f6a
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Apply method was added when CLI options for constructing the CLI were
rewritten into functional options in [cli@7f207f3]. There was no mention
in the pull request of this method specifically, and this may have been
related to work being done elsewhere on compose-on-kubernetes or the
compose-cli plugin that may have needed options to modify the CLI config
after it was already initialized.
The CLI itself no longer depends on this method since [cli@133279f], and
there are no known external users. It was deprecated in [cli@24bfedf],
which is included in the 28.5.0 release, so we can remove it for 29.0.
[cli@7f207f3]: 7f207f3f95
[cli@133279f]: 133279fb0d
[cli@24bfedf]: 24bfedf3f8
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Apply command was deprecated in 24bfedf3f8,
and has no known external users, but we didn't remove it from the interface.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used.
This method was deprecated in 0270b2d6f7,
which was included in the 28.5.0 release, and has no known external users,
so removing it for 29.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These options were used internally as defaults for the constructor and
only impact commands implemented in the CLI itself.
They were deprecated in 40cdfc0d81, which
was included in the 28.5.0 release, so removing it for 29.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used. Users should check
the value of the `DOCKER_CONTENT_TRUST` environment variable instead.
This method was deprecated in 11d40488dd,
which was included in the 28.5.0 release, and has no known external users,
so removing it for 29.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Apply method was added when CLI options for constructing the CLI were
rewritten into functional options in [cli@7f207f3]. There was no mention
in the pull request of this method specifically, and this may have been
related to work being done elsewhere on compose-on-kubernetes or the
compose-cli plugin that may have needed options to modify the CLI config
after it was already initialized.
The CLI itself no longer depends on this method since [cli@133279f], and
the only known consumer (docker compose) no longer needs it since [cli@2711800]
and [cli@048e931].
This patch deprecates the method with the intent to remove it in a future
release.
[cli@7f207f3]: 7f207f3f95
[cli@133279f]: 133279fb0d
[cli@2711800]: 2711800430
[cli@048e931]: 048e931b42
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used. Users should check
the value of the `DOCKER_CONTENT_TRUST` environment variable instead.
There are no known external users of this method, so already removing it
from the Cli interface; this method will be removed in the next release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These options were used internally as defaults for the constructor and
only impact commands implemented in the CLI itself.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This function was used internally, but is no longer used. There are
no known users of this method, so already removing it from the Cli
interface.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add support to the `cli/command` package to accept a custom User
Agent to pass to the underlying client.
This is used as the `UpstreamClient` portion of the `User-Agent`
when the Moby daemon makes requests.
For example, pushing and pulling images with Compose might result
in the registry seeing a `User-Agent` value of:
```
docker/24.0.7 go/go1.20.10 git-commit/311b9ff kernel/6.5.13-linuxkit os/linux arch/arm64 UpstreamClient(docker-cli-plugin-compose/v2.24.0)
```
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The Apply method was added when CLI options for constructing the CLI were
rewritten into functional options in [cli@7f207f3]. There was no mention
in the pull request of this method specifically, and this may have been
related to work being done elsewhere on compose-on-kubernetes or the
compose-cli plugin that may have needed options to modify the CLI config
after it was already initialized.
We should try to remove functions that mutate the CLI configuration after
initialization if possible (and likely remove the `Apply` method); currently
this function is used in docker compose, but as part of a hack that can
probably be avoided.
[cli@7f207f3]: 7f207f3f95
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
We may still change this, but in the client module, the signature
of the client.Opt changed to now include a non-exported type, which
means that we can't construct a custom option that is implemented
using client options:
#18 16.94 # github.com/docker/cli/cli/context/docker
#18 16.94 cli/context/docker/load.go:105:29: cannot use withHTTPClient(tlsConfig) (value of type func(*client.Client) error) as client.Opt value in argument to append
#18 16.94 cli/context/docker/load.go:152:6: cannot use c (variable of type *client.Client) as *client.clientConfig value in argument to client.WithHTTPClient(&http.Client{…})
We can consider exporting the `client.clientConfig` type (but keep its
fields non-exported), but for this use, we don't strictly need it, so
let's change the implementation to not having to depend on that.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Go maintainers started to unconditionally update the minimum go version
for golang.org/x/ dependencies to go1.23, which means that we'll no longer
be able to support any version below that when updating those dependencies;
> all: upgrade go directive to at least 1.23.0 [generated]
>
> By now Go 1.24.0 has been released, and Go 1.22 is no longer supported
> per the Go Release Policy (https://go.dev/doc/devel/release#policy).
>
> For golang/go#69095.
This updates our minimum version to go1.23, as we won't be able to maintain
compatibility with older versions because of the above.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
In most situations, the CLI is created through the `NewDockerCli` constructor,
however, it's possible to construct a CLI manually (`&DockerCli{}`). We
should probably prevent this (and un-export the `DockerCli` implementation),
but currently have some code-paths that depend on the type being exported.
When constructing the CLI with this approach, the CLI would not be fully
initialized and not have the context-store configuration set up.
Using the default context store without a config set will result in Endpoints
from contexts not being type-mapped correctly, and used as a generic
`map[string]any`, instead of a [docker.EndpointMeta].
When looking up the API endpoint (using [EndpointFromContext]), no endpoint
will be found, and a default, empty endpoint will be used instead which in
its turn, causes [newAPIClientFromEndpoint] to be initialized with the default
config instead of settings for the current context (which may mean; connecting
with the wrong endpoint and/or TLS Config to be missing).
I'm not sure if this situation could happen in practice, but it caused some
of our unit-tests ([TestInitializeFromClient] among others) to fail when
running outside of the dev-container on a host that used Docker Desktop's
"desktop-linux" context. In that situation, the test would produce the wrong
"Ping" results (using defaults, instead of the results produced in the test).
This patch:
- updates the contextStoreConfig field to be a pointer, so that we are
able to detect if a config was already set.
- updates the `Initialize` function to set the default context-store config
if no config was found (technically the field is mostly immutable, and
can only set through `WithDefaultContextStoreConfig`, so this may be
slightly redundant).
We should update this code to be less error-prone to use; the combination
of an exported type (`DockerCli`), a constructor `NewDockerCli` and a
`Initialize` function (as well as some internal contructors to allow
lazy initialization) make constructing the "CLI" hard to use, and there's
various codepaths where it can be in a partially initialized state. The
same applies to the default context store, which also requires too much
"domain" knowledge to use properly.
I'm leaving improvements around that for a follow-up.
[EndpointFromContext]: 33494921b8/cli/context/docker/load.go (L139-L149)
[docker.EndpointMeta]: 33494921b8/cli/context/docker/load.go (L19-L21)
[newAPIClientFromEndpoint]: 33494921b8/cli/command/cli.go (L295-L305)
[TestInitializeFromClient]: 33494921b8/cli/command/cli_test.go (L157-L205)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This method was a shallow wrapper around registryclient.NewRegistryClient but
due to its signature resulted in various dependencies becoming a dependency
of the "command" package. Consequence of this was that cli-plugins, which
need the cli/command package, would also get those dependencies. It is no
longer used, and was deprecated in 8ad07217dc.
This patch removes the RegistryClient method from the interface
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This method is a shallow wrapper around trust.GetNotaryRepository, but
due to its signature resulted in the trust package, and notary dependencies
to become a dependency of the CLI. Consequence of this was that cli-plugins,
which need the cli/command package, would also get notary and its
dependencies as a dependency. It is no longer used, and was deprecated
in 9bc16bbde0.
This patch removes the NotaryClient method from the interface
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
It's hard-coded to the API defaultversion, so we can use
that const directly. Ultimately, this should be something
returned by the API client configured on the CLI, not the
CLI itself.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The DOCKER_CLI_HINTS env-var is replaced by DOCKER_CLI_HOOKS; check the
new env-var first, and only fall back to checking the legacy env-var
if it's not set.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This method was a shallow wrapper around registryclient.NewRegistryClient but
due to its signature resulted in various dependencies becoming a dependency
of the "command" package. Consequence of this was that cli-plugins, which
need the cli/command package, would also get those dependencies. It is no
longer used in our code, which constructs the client in packages that need it,
so we can deprecate this method.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This method is a shallow wrapper around manifeststore.NewStore, but
due to its signature resulted in various dependencies becoming a dependency
of the "command" package. Consequence of this was that cli-plugins, which
need the cli/command package, would also get those dependencies. It is no
longer used in our code, which constructs the client in packages that need it,
so we can deprecate this method.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This method is a shallow wrapper around trust.GetNotaryRepository, but
due to its signature resulted in the trust package, and notary dependencies
to become a dependency of the CLI. Consequence of this was that cli-plugins,
which need the cli/command package, would also get notary and its
dependencies as a dependency. It is no longer used in our code, which
constructs the client in packages that need it, so we can deprecate this
method.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
These utility functions were added in 8890a1c929,
and are all related to OTEL. The ResourceAttributesEnvvar const defines
the "OTEL_RESOURCE_ATTRIBUTES" environment-variable to use, which is part
of the [OpenTelemetry specification], so should be considered a well-known
env-var, and not up to us to define a const for. These code-changes were not
yet included in a release, so we don't have to deprecate.
This patch:
- Moves the utility functions to the telemetry files, so that all code related
to OpenTelemetry is together.
- Un-exports the ResourceAttributesEnvvar to reduce our public API.
- Un-exports the DockerCliAttributePrefix to reduce depdency on cli/command
in CLI-plugins, but adds a TODO to move telemetry-related code to a common
(internal) package.
- Deprecates the cli-plugins/manager.ResourceAttributesEnvvar const. This
const has no known consumers, so we could skip deprecation, but just in
case some codebase uses this.
[OpenTelemetry specification]: https://opentelemetry.io/docs/specs/otel/configuration/sdk-environment-variables/#general-sdk-configuration
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Remove the `docker.cli` prefixed attributes from
`OTEL_RESOURCE_ATTRIBUTES` after the telemetry provider has been created
within a plugin. This prevents accidentally sending the attributes to
something downstream for the user.
This also fixes an issue with compose where the self-injected `OTEL_RESOURCE_ATTRIBUTES`
would override an existing attribute in the environment file because the
"user environment" overrode the environment file, but the "user
environment" was created by the `docker` tool rather than by the user's
environment.
When `OTEL_RESOURCE_ATTRIBUTES` is empty after pruning, the environment
variable is unset.
Signed-off-by: Jonathan A. Sternberg <jonathan.sternberg@docker.com>
cli/command/cli.go💯7: unused-receiver: method receiver 'cli' is not referenced in method's body, consider removing or renaming it as _ (revive)
func (cli *DockerCli) DefaultVersion() string {
^
cli/command/cli.go:234:7: unused-receiver: method receiver 'cli' is not referenced in method's body, consider removing or renaming it as _ (revive)
func (cli *DockerCli) ManifestStore() manifeststore.Store {
^
cli/command/telemetry.go:57:7: unused-receiver: method receiver 'cli' is not referenced in method's body, consider removing or renaming it as _ (revive)
func (cli *DockerCli) TracerProvider() trace.TracerProvider {
^
cli/command/telemetry.go:61:7: unused-receiver: method receiver 'cli' is not referenced in method's body, consider removing or renaming it as _ (revive)
func (cli *DockerCli) MeterProvider() metric.MeterProvider {
^
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- use Println to print newline instead of custom format
- suppress some errors to make my IDE and linters happier
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
commit 4a7b04d412 configured golangci-lint
to use go1.23 semantics, which enabled the copyloopvar linter.
go1.22 now creates a copy of variables when assigned in a loop; make sure we
don't have files that may downgrade semantics to go1.21 in case that also means
disabling that feature; https://go.dev/ref/spec#Go_1.22
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
