Plugins are expected to be management commands ("docker <object> <verb>").
This patch modified the usage output to shown plugins in the "Management commands"
section.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is a bit manual (as the unit test attests) so we may find we want to add
some helpers/accessors, but this is enough to let plugins use it and to
preserve the information through round-trips.
Signed-off-by: Ian Campbell <ijc@docker.com>
- The placement of the vendor is now in the end of the line.
- A '*' is now added as suffix of plugins' top level commands.
Signed-off-by: Ulysses Souza <ulysses.souza@docker.com>
This means that plugins can use whatever methods the monolithic CLI supports,
which is good for consistency.
This relies on `os.Args[0]` being something which can be executed again to
reach the same binary, since it is propagated (via an envvar) to the plugin for
this purpose. This essentially requires that the current working directory and
path are not modified by the monolithic CLI before it launches the plugin nor
by the plugin before it initializes the client. This should be the case.
Previously the fake apiclient used by `TestExperimentalCLI` was not being used,
since `cli.Initialize` was unconditionally overwriting it with a real one
(talking to a real daemon during unit testing, it seems). This wasn't expected
nor desirable and no longer happens with the new arrangements, exposing the
fact that no `pingFunc` is provided, leading to a panic. Add a `pingFunc` to
the fake client to avoid this.
Signed-off-by: Ian Campbell <ijc@docker.com>
Fairly straight forward. It became necessary to wrap `Plugin.Err` with a type
which implements `encoding.MarshalText` in order to have that field rendered
properly in the `docker info -f '{{json}}'` output.
Since I changed the type somewhat I also added a unit test for `formatInfo`.
Signed-off-by: Ian Campbell <ijc@docker.com>
To do this we add a stub `cobra.Command` for each installed plugin (only when
invoking `help`, not for normal running).
This requires a function to list all available plugins so that is added here.
Signed-off-by: Ian Campbell <ijc@docker.com>
Also includes the scaffolding for finding a validating plugin candidates.
Argument validation is moved to RunE to support this, so `noArgs` is removed.
Signed-off-by: Ian Campbell <ijc@docker.com>
- The `/build/prune` endpoint was added in API v1.31
- The `/network` endpoints were added in API v1.21
This patch hides these commands on older API versions
Before this change:
```
DOCKER_API_VERSION=1.0 docker
...
Management Commands:
builder Manage builds
container Manage containers
image Manage images
manifest Manage Docker image manifests and manifest lists
network Manage networks
system Manage Docker
trust Manage trust on Docker images
```
After this change
```
DOCKER_API_VERSION=1.0 docker
...
Management Commands:
container Manage containers
image Manage images
manifest Manage Docker image manifests and manifest lists
system Manage Docker
trust Manage trust on Docker images
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
That is, the helper to be used from the plugin's `main`.
Also add a `helloworld` plugin example and build integration.
Signed-off-by: Ian Campbell <ijc@docker.com>
I authored this for `contentTrustEnabled` prior to 7f207f3f95, so this now
tests the funcation argument version.
Signed-off-by: Ian Campbell <ijc@docker.com>
This helps to avoid circular includes, by separating the pure data out from the
actual functionality in the cli subpackage, allowing other code which is
imported to access the data.
Signed-off-by: Ian Campbell <ijc@docker.com>
... and expose. I would like to use this from another site.
This implies also moving (and exposing) the `visitAll` helper.
Unit test them while I'm here.
Signed-off-by: Ian Campbell <ijc@docker.com>
All of the current callers follow the pattern:
dockerPreRun(opts)
err := dockerCli.Initialize(opts) ...
So there is no semantic change into merging the content of `dockerPreRun` into the head of `Initialize`.
I'm about to add a new caller outside of the `cmd/docker` package and this
seems preferable exporting `DockerPreRun`.
Signed-off-by: Ian Campbell <ijc@docker.com>
This will allow plugins to have custom typed endpoints, as well as
create/remove/update contexts with the exact same results as the main
CLI (thinking of things like `docker ee login https://my-ucp-server
--context ucp-prod)`
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
That is, reindent the two sections by one space.
While the code was done by hand the `.golden` files had the extra space
inserted with emacs' `string-insert-rectangle` macro to (try to) avoid possible
manual errors. The docs were edited the same way.
Signed-off-by: Ian Campbell <ijc@docker.com>
Right now the only client side info we have is whether debug is enabled, but we
expect more in the future.
We also preemptively prepare for the possibility of multiple errors when
gathering both daemon and client info.
Signed-off-by: Ian Campbell <ijc@docker.com>
Last batch of modifications to the context switch implementation missed
some documentation updates. This is an update to the CLI reference and
the store implementation Godoc.
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Proxies configured in config.json were only taking effect
when using `docker run`, but were being ignored when
using `docker create`.
Before this change:
echo '{"proxies":{"default":{"httpProxy":"httpProxy","httpsProxy":"httpsProxy","noProxy":"noProxy","ftpProxy":"ftpProxy"}}}' > config.json
docker inspect --format '{{.Config.Env}}' $(docker --config=./ create busybox)
[PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
With this change applied:
echo '{"proxies":{"default":{"httpProxy":"httpProxy","httpsProxy":"httpsProxy","noProxy":"noProxy","ftpProxy":"ftpProxy"}}}' > config.json
docker inspect --format '{{.Config.Env}}' $(docker --config=./ create busybox)
[NO_PROXY=noProxy no_proxy=noProxy FTP_PROXY=ftpProxy ftp_proxy=ftpProxy HTTP_PROXY=httpProxy http_proxy=httpProxy HTTPS_PROXY=httpsProxy https_proxy=httpsProxy PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin]
Reported-by: Silvano Cirujano Cuesta <Silvanoc@users.noreply.github.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `DOCKER_HIDE_LEGACY_COMMANDS` environment variable allows hiding legacy
top-level commands that are now available under `docker <object> <verb>`. The
`docker deploy` top-level command is experimental, and replaced by
`docker stack deploy`.
This patch hides the top-level `docker deploy` if the `DOCKER_HIDE_LEGACY_COMMANDS`
environment variable is set.
Before this change:
DOCKER_HIDE_LEGACY_COMMANDS=1 docker --help
...
Commands:
build Build an image from a Dockerfile
deploy Deploy a new stack or update an existing stack
login Log in to a Docker registry
logout Log out from a Docker registry
run Run a command in a new container
search Search the Docker Hub for images
version Show the Docker version information
...
With this patch applied:
DOCKER_HIDE_LEGACY_COMMANDS=1 docker --help
...
Commands:
build Build an image from a Dockerfile
login Log in to a Docker registry
logout Log out from a Docker registry
run Run a command in a new container
search Search the Docker Hub for images
version Show the Docker version information
...
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This PR adds a store to the CLI, that can be leveraged to persist and
retrieve credentials for various API endpoints, as well as
context-specific settings (initially, default stack orchestrator, but we
could expand that).
This comes with the logic to persist and retrieve endpoints configs
for both Docker and Kubernetes APIs.
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
Add `--quiet` to the `docker image pull` subcommand that will not pull
the image quietly.
```
$ docker pull -q golang
Using default tag: latest
```
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Previously, these errors were only printed when using `docker run`, but were
omitted when using `docker container create` and `docker container start`
separately.
Given that these warnings apply to both situations, this patch moves generation
of these warnings to `docker container create` (which is also called by
`docker run`)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
A while ago, Docker split the "Domainname" field out from the "Hostname"
field for the container configuration. There was no real user-visible
change associated with this (and under the hood "Domainname" was mostly
left unused from the command-line point of view). We now add this flag
in order to match other proposed changes to allow for setting the NIS
domainname of a container.
This also includes a fix for the --hostname parsing tests (they would
not error out if only one of .Hostname and .Domainname were incorrectly
set -- which is not correct).
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This PR chnages allow user to configure data path
port number. By default we use 4789 port number. But this commit
will allow user to configure port number during swarm init.
Data path port can't be modified after swarm init.
Signed-off-by: selansen <elango.siva@docker.com>
A recent change in moby/moby made tests with missing client mocks fail with panic.
This adds those missing mocks for the impacted tests.
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
- make it possible to extract the formatter implementation from the
"common" code, that way, the formatter package stays small
- extract some formatter into their own packages
This is essentially moving the "formatter" implementation of each type
in their respective packages. The *main* reason to do that, is to be
able to depend on `cli/command/formatter` without depending of the
implementation detail of the formatter. As of now, depending on
`cli/command/formatter` means we depend on `docker/docker/api/types`,
`docker/licensing`, … — that should not be the case. `formatter`
should hold the common code (or helpers) to easily create formatter,
not all formatter implementations.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Avoid testing for session support in non-buildkit builder to support
servers that falsely report as `1.39` compatible
Signed-off-by: Tibor Vass <tibor@docker.com>
Sebastiaan van Stijn
Ian Campbell
Silvin Lubecki
Sebastiaan van Stijn
Olli Janatuinen
Ulysses Souza
Lifubang
Tibor Vass
Philipp Schmied
Vincent Demeester
John Howard
Tonis Tiigi
Simon Ferquel
Silvin Lubecki
François Scala
JoeWrightss
Akihiro Suda
Daniel Hiltgen
Jérémie Drouet
Tibor Vass
Aleksa Sarai
selansen
Brian Goff