The linter is complaining:
cmd/docker/docker.go:72:23⚠️ dockerCli can be github.com/docker/cli/cli/command.Cli (interfacer)
Unclear precisely which change in the preceeding commits caused it to notice
this possibility.
Signed-off-by: Ian Campbell <ijc@docker.com>
Previously `docker --badopt` would always include experimental commands even if
experimental was not enabled.
Signed-off-by: Ian Campbell <ijc@docker.com>
With this patch it is possible to alias an existing allowed command.
At the moment only builder allows an alias.
This also properly puts the build command under builder, instead of image
where it was for historical reasons.
Signed-off-by: Tibor Vass <tibor@docker.com>
Before calling `cmd.Execute` we need to reset the arguments to be used to not
include the global arguments which we have already parsed. This is precisely
the `args` which we have in our hand at this point.
This fixes `TestGlobalArgsOnlyParsedOnce/builtin` in the cli-plugins e2e tests.
`TestGlobalArgsOnlyParsedOnce/plugin` is still broken will be fixed next.
Signed-off-by: Ian Campbell <ijc@docker.com>
The issue with plugin options clashing with globals is that when cobra is
parsing the command line and it comes across an argument which doesn't start
with a `-` it (in the absence of plugins) distinguishes between "argument to
current command" and "new subcommand" based on the list of registered sub
commands.
Plugins breaks that model. When presented with `docker -D plugin -c foo` cobra
parses up to the `plugin`, sees it isn't a registered sub-command of the
top-level docker (because it isn't, it's a plugin) so it accumulates it as an
argument to the top-level `docker` command. Then it sees the `-c`, and thinks
it is the global `-c` (for AKA `--context`) option and tries to treat it as
that, which fails.
In the specific case of the top-level `docker` subcommand we know that it has
no arguments which aren't `--flags` (or `-f` short flags) and so anything which
doesn't start with a `-` must either be a (known) subcommand or an attempt to
execute a plugin.
We could simply scan for and register all installed plugins at start of day, so
that cobra can do the right thing, but we want to avoid that since it would
involve executing each plugin to fetch the metadata, even if the command wasn't
going to end up hitting a plugin.
Instead we can parse the initial set of global arguments separately before
hitting the main cobra `Execute` path, which works here exactly because we know
that the top-level has no non-flag arguments.
One slight wrinkle is that the top-level `PersistentPreRunE` is no longer
called on the plugins path (since it no longer goes via `Execute`), so we
arrange for the initialisation done there (which has to be done after global
flags are parsed to handle e.g. `--config`) to happen explictly after the
global flags are parsed. Rather than make `newDockerCommand` return the
complicated set of results needed to make this happen, instead return a closure
which achieves this.
The new functionality is introduced via a common `TopLevelCommand` abstraction
which lets us adjust the plugin entrypoint to use the same strategy for parsing
the global arguments. This isn't strictly required (in this case the stuff in
cobra's `Execute` works fine) but doing it this way avoids the possibility of
subtle differences in behaviour.
Fixes#1699, and also, as a side-effect, the first item in #1661.
Signed-off-by: Ian Campbell <ijc@docker.com>
They were listed twice in `docker --help` (but not `docker help`), since the
stubs were added in both `tryRunPluginHelp` and the `setHelpFunc` closure.
Calling `AddPluginStubCommands` earlier in `setHelpFunc` before the call to
`tryRunPluginHelp` is sufficient. Also it is no longer necessary to add just
valid plugins (`tryRunPluginHelp` handles invalid plugins correctly) so remove
that logic (which was in any case broken for e.g. `docker --help`).
Update the e2e test to check for duplicate entries and also to test `docker
--help` which was previously missed.
Signed-off-by: Ian Campbell <ijc@docker.com>
This allows passing argument to plugins, otherwise they are caught by the parse
loop, since cobra does not know about each plugin at this stage (to avoid
having to always scan for all plugins) this means that e.g. `docker plugin
--foo` would accumulate `plugin` as an arg to the `docker` command, then choke
on the unknown `--foo`.
This allows unknown global args only, unknown arguments on subcommands (e.g.
`docker ps --foo`) are still correctly caught.
Add an e2e test covering this case.
Signed-off-by: Ian Campbell <ijc@docker.com>
To achieve this we hook in at the beginning of our custom `HelpFunc` and detect
the plugin case by adding stub commands.
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>
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>
Starting with a3fe7d62b8,
`docker invalid-subcommand` did not exit with non-zero status.
Fix#1428
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
* Renaming DOCKER_ORCHESTRATOR to DOCKER_STACK_ORCHESTRATOR
* Renaming config file option "orchestrator" to "stackOrchestrator"
* "--orchestrator" flag is no more global but local to stack command and subcommands
* Cleaning all global orchestrator code
* Replicating Hidden flags in help and Supported flags from root command to stack command
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
This patch adds annotations to mark the checkpoint commands as Linux only, which
hides them if the daemon is running a non-matching operating-system type;
Before:
docker
Usage: docker COMMAND
A self-sufficient runtime for containers
...
Management Commands:
config Manage Docker configs
container Manage containers
image Manage images
After:
docker
Usage: docker COMMAND
A self-sufficient runtime for containers
...
Management Commands:
checkpoint Manage checkpoints
config Manage Docker configs
container Manage containers
image Manage images
This change also prints errors when attempting to use checkpoint commands or
flags if the feature is not supported by the Daemon's operating system;
$ docker checkpoint --help
docker checkpoint is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker checkpoint create --help
docker checkpoint create is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker checkpoint ls --help
docker checkpoint ls is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker checkpoint rm --help
docker checkpoint rm is only supported on a Docker daemon running on linux, but the Docker daemon is running on windows
$ docker container start --checkpoint=foo mycontainer
"--checkpoint" requires the Docker daemon to run on linux, but the Docker daemon is running on windows
$ docker container start --checkpoint-dir=/foo/bar mycontainer
"--checkpoint-dir" requires the Docker daemon to run on linux, but the Docker daemon is running on windows
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch hides the [flags] in the usage output of commands, using the
new `.DisableFlagsInUseLine` option, instead of the temporary workaround
added in 8e600e10f7
Before this change:
docker run
"docker run" requires at least 1 argument.
See 'docker run --help'.
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...] [flags]
Run a command in a new container
After this change:
docker run
"docker run" requires at least 1 argument.
See 'docker run --help'.
Usage: docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
Run a command in a new container
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- `replaceDockerfileForContentTrust` is only used when content trust is
enabled, so remove the boolean.
- rename `isContentTrustEnabled` to `contentTrustEnabled`
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
- More strict on orchestrator flag
- Make orchestrator flag more explicit as experimental
- Add experimentalCLI annotation on kubernetes flags
- Better kubeconfig error message
- Prefix service name with stackname in ps and services stack subcommands
- Fix yaml documentation
- Fix code coverage ignoring generated code
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
* Refactor tests on version and kubernetes switch
* Fix rebase errors
* Refactor for gocyclo linter
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
- Define command and subcommands only once
- Use annotations for k8s or swarm specific flags or subcommands
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Allow to mark some commands and flags experimental on cli (i.e. not
depending to the state of the daemon). This will allow more flexibility
on experimentation with the cli.
Marking `docker trust` as cli experimental as it is documented so.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
The `docker daemon` subcommand was only present for
backward compatibility, but deprecated in v1.13,
and scheduled for removal in v17.12
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- The cli version defaults to "unknown-version" unless set via the VERSION env var
- The commit version can be overridden via GITCOMMIT env var
- The build time can be overridden via BUILDTIME env var
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Ian Campbell
Tibor Vass
Simon Ferquel
Corey Quon
Silvin Lubecki
Silvin Lubecki
Sebastiaan van Stijn
Akihiro Suda
Vincent Demeester
Sebastiaan van Stijn
Daniel Nephin
Kenfe-Mickael Laventure
Daniel Nephin