mirror of
https://github.com/docker/cli.git
synced 2026-01-13 18:22:35 +03:00
ed0511251d
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>
Docker CLI
About
This repository is the home of the Docker CLI.
Development
docker/cli is developed using Docker.
Build CLI from source:
docker buildx bake
Build binaries for all supported platforms:
docker buildx bake cross
Build for a specific platform:
docker buildx bake --set binary.platform=linux/arm64
Build dynamic binary for glibc or musl:
USE_GLIBC=1 docker buildx bake dynbinary
Run all linting:
docker buildx bake lint shellcheck
Run test:
docker buildx bake test
List all the available targets:
make help
In-container development environment
Start an interactive development environment:
make -f docker.Makefile shell
Legal
Brought to you courtesy of our legal counsel. For more context, see the NOTICE document in this repo.
Use and transfer of Docker may be subject to certain restrictions by the United States and other governments.
It is your responsibility to ensure that your use and/or transfer does not violate applicable laws.
For more information, see https://www.bis.doc.gov
Licensing
docker/cli is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.