When deploying a stack using a relative path as bind-mount
source in the compose file, the CLI converts the relative
path to an absolute path, relative to the location of the
docker-compose file.
This causes a problem when deploying a stack that uses
an absolute Windows path, because a non-Windows client will
fail to detect that the path (e.g. `C:\somedir`) is an absolute
path (and not a relative directory named `C:\`).
The existing code did already take Windows clients deploying
a Linux stack into account (by checking if the path had a leading
slash). This patch adds the reverse, and adds detection for Windows
absolute paths on non-Windows clients.
The code used to detect Windows absolute paths is copied from the
Golang filepath package;
1d0e94b1e1/src/path/filepath/path_windows.go (L12-L65)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit d6dd08d568)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Refactor `RunCreate` slightly so that all three paths always produce the same
output, namely the name of the new context of `stdout` (for scripting) and the
success log message on `stderr`.
Validate by extending the existing unit tests to always check the output is as
expected.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit ff44305c47)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This code was attempting to check Linux file permissions
to determine if the key was accessible by other users, which
doesn't work, and therefore prevented users on Windows
to load keys.
Skipping this check on Windows (correspinding tests
were already skipped).
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 15d361fd77)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
For backward compatibility: if no custom options are provided for the network,
and only a single network is specified, omit the endpoint-configuration
on the client (the daemon will still create it when creating the container)
This fixes an issue on older versions of legacy Swarm, which did not support
`NetworkingConfig.EndpointConfig`.
This was introduced in 5bc09639cc (#1767)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 4d7e6bf629)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds capabilities to import a .zip file with importZip.
Detects the content type of source by checking bytes & DetectContentType.
Adds LimitedReader reader, a fork of io.LimitedReader,
was needed for better error messaging instead of just getting back EOF.
We are using limited reader to avoid very big files causing memory issues.
Adds a new file size limit for context imports,
this limit is used for the main file for .zip & .tar and individual compressed
files for .zip.
Added TestImportZip that will check the import content type
Then will assert no err on Importing .zip file
Signed-off-by: Goksu Toprak <goksu.toprak@docker.com>
(cherry picked from commit 291e86289b)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This is less of a layering violation and removes some ugly hardcoded
`"kubernetes"` strings which were needed to avoid an import loop.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit c455193d14)
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
This removes the need for the core context code to import
`github.com/docker/cli/cli/context/kubernetes` which in turn reduces the
transitive import tree in this file to not pull in all of Kubernetes.
Note that this means that any calling code which is interested in the
kubernetes endpoint must import `github.com/docker/cli/cli/context/kubernetes`
itself somewhere in order to trigger the dynamic registration. In practice
anything which is interested in Kubernetes must import that package (e.g.
`./cli/command/context.list` does for the `EndpointFromContext` function) to do
anything useful, so this restriction is not too onerous.
As a special case a small amount of Kubernetes related logic remains in
`ResolveDefaultContext` to handle error handling when the stack orchestrator
includes Kubernetes. In order to avoid a circular import loop this hardcodes
the kube endpoint name.
Similarly to avoid an import loop the existing `TestDefaultContextInitializer`
cannot continue to unit test for the Kubernetes case, so that aspect of the
test is carved off into a very similar test in the kubernetes context package.
Lastly, note that the kubernetes endpoint is now modifiable via
`WithContextEndpointType`.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit 520be05c49)
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
These are needed by any dynamically registered (via
`RegisterDefaultStoreEndpoints`) endpoint type to write a useful/sensible unit
test.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit f820766f6a)
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
Previously an endpoint registered using `RegisterDefaultStoreEndpoints` would
not be taken into consideration by `resolveDefaultContext` and so could not
provide any details.
Resolve this by passing a `store.Config` to `resolveDefaultContext` and using
it to iterate over all registered endpoints. Any endpoint can ensure that their
type implements the new `EndpointDefaultResolver` in order to provide a default.
The Docker and Kubernetes endpoints are special cased, shortly the Kubernetes
one will be refactored to be dynamically registered.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit 1433e27420)
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
This is a yet unused and the default set remains the same, no expected
functional change.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit 087c3f7d08)
Signed-off-by: Silvin Lubecki <silvin.lubecki@docker.com>
The comment on `github.com/docker/cli/kubernetes.NewKubernetesConfig` said:
// Deprecated: Use github.com/docker/compose-on-kubernetes/api.NewKubernetesConfig instead
By making this switch in `github.com/docker/cli/context/kubernetes/load.go` we
break a vendoring chain:
`github.com/docker/cli/cli/command`
→ `vendor/github.com/docker/cli/cli/context/kubernetes/load.go`
→ `vendor/github.com/docker/cli/kubernetes`
→ `github.com/docker/compose-on-kubernetes/api/compose/...`
This means that projects which just want `github.com/docker/cli/cli/command`
(which is itself pulled in transitively by
`github.com/docker/cli/cli-plugins/plugin`) which do not themselves need the
compose-on-kubernetes API avoid a huge pile of transitive dependencies.
On one of my private projects the diff on the vendor dir is:
280 files changed, 21 insertions(+), 211346 deletions(-)
and includes dropping:
* `github.com/docker/compose-on-kubernetes/api/compose/{clone,impersonation}`
* `github.com/docker/compose-on-kubernetes/api/compose/{v1alpha3,v1beta1,v1beta2,v1beta3}`
* `github.com/google/btree`
* `github.com/googleapis/gnostic`
* `github.com/gregjones/httpcache`
* `github.com/peterbourgon/diskv`
* `k8s.io/api/*` (_lots_ of subpackages)
* `k8s.io/client-go/{discovery,kubernetes/scheme}`
and I've gone from:
$ du -sh vendor/k8s.io/
8.1M vendor/k8s.io/
to:
$ du -sh vendor/k8s.io/
2.1M vendor/k8s.io/
(overall I went from 36M → 29M of vendor dir for this particular project)
The change to `cli/command/system/version.go` is just for consistency and
allows us to drop the now unused alias.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit 8635abd662)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The (small number) of other places which name this import use `kubecontext`,
make it consistent.
Signed-off-by: Ian Campbell <ijc@docker.com>
(cherry picked from commit 1e5129f027)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
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>
This is to make it easier to implement support for exporting contexts in
3rd party code, or to create mocks in tests.
2 exemples where it simplify things:
- docker-app desktop-specific context decorator (which rewrites parts of
the docker context to simplify UX when using on Docker Desktop contexts)
- ucp for including a context in the connection bundle
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
This change refines the warning message returned during docker login to
only warn for unencrypted storage when the users password is being stored.
If the remote registry supports identity tokens, omit the warning,
since those tokens can be independently managed and revoked.
Signed-off-by: Daniel Hiltgen <daniel.hiltgen@docker.com>
The github.com/flynn-archive/go-shlex package is a fork of Google/shlex,
and the repository is now archived, so let's switch to the maintained
version.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Adds tests for setting and updating swarm service CredentialSpecs,
especially when using a Config as a credential spec.
Signed-off-by: Drew Erny <drew.erny@docker.com>
Updates the CredentialSpec handling code for services to allow using
swarm Configs.
Additionally, fixes a bug where the `--credential-spec` flag would not
be respected on service updates.
Signed-off-by: Drew Erny <drew.erny@docker.com>
This regroup all Kubernetes extra fields for compose-on-kubernetes
v1alpha3 in a single x-kubernetes object.
Also use the same naming scheme as cap_add etc. for fiels inside this
object.
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
On the server v0.4.21 has introduced a better way of dealing with
intra-stack networking: if the user can specify a list of endpoints
exposed internally, we now can setup a ClusterIP for this to avoid the
pitfalls of DNS-based load balancing.
This exposes the feature using the "Expose" compose field, and adds an
extra x-internal-service-type field to explicitly define how intra-stack
networking is handled on a service.
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
For clarity, on `docker context use` or `docker context ls`, this adds a
warning if the DOCKER_HOST variable is set because it overrides the
active context.
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
This refactors the way networking options are parsed, and makes the
client able to pass options for multiple networks. Currently, the
daemon does not yet accept multiple networks when creating a container,
and will produce an error.
For backward-compatibility, the following global networking-related
options are associated with the first network (in case multiple
networks are set);
- `--ip`
- `--ip6`
- `--link`
- `--link-local-ip`
- `--network-alias`
Not all of these options are supported yet in the advanced notation,
but for options that are supported, setting both the per-network option
and the global option will produce a "conflicting options" error.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The commit contains cli changes to support driver options for a network in
docker run and docker network connect cli's. The driver-opt, aliases is now
supported in the form of csv as per network option in service commands in
swarm mode since docker/cli#62 . This commit extends this support to docker
run command as well.
For docker connect command `--driver-opt` is added to pass driver specific
options for the network the container is connecting to.
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
--from creates a context from a named context.
By default `context create` will create a context from the current context.
Replaced "from-current=" docker/kubernetes option with "from=" to allow specifying which context to copy the settings from.
Signed-off-by: Nick Adcock <nick.adcock@docker.com>
Old selector was wrong (it watched for the label we applied to child
resources when reconciling the stack, instead of the stack itself)
This should be back-ported to older version of the CLI
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
bump required:
- replacing vendor ghodss/yaml with sigs.k8s.io/yaml
- adding vendor k8s.io/klog and github.com/evanphx
- compose-on-kubernetes
removed 'IncludeUninitialized' from watch as it have been removed from k8s
Signed-off-by: Nick Adcock <nick.adcock@docker.com>
Instead of using an `if else if else`, switch to a sequence of independent
`if` blocks containing a `return`.
Instead of defining a return variable and updating it in the `if` blocks
and returning at the end, make each `if` block return the desired value
independenly.
Signed-off-by: David Scott <dave.scott@docker.com>
Previously if the Docker engine was not running the behaviour of
commands would vary depending on whether the --debug flag was provided.
For example, consider `docker logout`:
$ docker logout
Not logged in to
-- note the missing server URL
$ docker --debug logout
Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?). Using system default: https://index.docker.io/v1/
Not logged in to https://index.docker.io/v1/
-- note the server URL is present
This patch makes only the debug printing conditional on the `--debug` flag,
not the return value.
Signed-off-by: David Scott <dave.scott@docker.com>
In the initial implementation I thought it would be good to not pass on the
deprecation to plugins (since they are new). However it turns out this causes
`docker helloworld -h` to print a spurious "pflag: help requested" line:
$ docker helloworld -h
pflag: help requested
See 'docker helloworld --help'.
Usage: docker helloworld [OPTIONS] COMMAND
A basic Hello World plugin for tests
...
Compared with:
$ docker ps -h
Flag shorthand -h has been deprecated, please use --help
Usage: docker ps [OPTIONS]
This is in essence because having the flag undefined hits a different path
within cobra, causing `c.execute()` to return early due to getting an error
(`flag.ErrHelp`) from `c.ParseFlags`, which launders the error through our
`FlagErrorFunc` which wraps it in a `StatusError` which in turn defeats an `if
err == flag.ErrHelp` check further up the call chain. If the flag is defined we
instead hit a path which returns a bare `flag.ErrHelp` without wrapping it.
I considered updating our `FlagErrorFunc` to not wrap `flag.ErrHelp` (and then
following the chain to the next thing) however while doing that I realised that
the code for `-h` (and `--help`) is deeply embedded into cobra (and its flags
library) such that actually using `-h` as a plugin argument meaning something
other than `help` is basically impossible/impractical. Therefore we may as well
have plugins behave identically to the monolithic CLI and support (deprecated)
the `-h` argument.
With this changed the help related blocks of `SetupRootCommand` and
`SetupPluginRootCommand` are now identical, so consolidate into
`setupCommonRootCommand`.
Tests are updated to check `-h` in a variety of scenarios, including the happy
case here.
Signed-off-by: Ian Campbell <ijc@docker.com>
As pointed out in #1459, docker cli fails to detect that the input is a tarball,
in case it is generated by `git archive --format=tgz`.
This happens because `git archive` adds some metadata to the initial tar header,
and so it is more than 1 block (of 512 bytes) long, while we only provide 1 block
to archive/tar.Next() and it fails.
To fix, give it 2 blocks :)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This adds validation to `docker container run` / `docker container create`;
Validation of labels provided through flags was removed in 31dc5c0a9a,
after the validation was changed to fix labels without values, and to prevent
labels from being expanded with environment variables in 2b17f4c8a8
However, now empty label names from _files_ (`--label-file`) followed different
validation rules than labels passed through `--label`.
This patch adds back minimal validation for labels passed through the command-line
Before this patch:
```bash
docker container create \
--name label \
--label==with-leading-equal-sign \
--label=without-value \
--label=somelabel=somevalue \
--label " = " \
--label=with-quotes-in-value='{"foo"}' \
--label='with"quotes"in-key=test' \
busybox
docker container inspect --format '{{json .Config.Labels}}' label
```
```json
{
"": "with-leading-equal-sign",
" ": " ",
"somelabel": "somevalue",
"with\"quotes\"in-key": "test",
"with-quotes-in-value": "{\"foo\"}",
"without-value": ""
}
```
After this patch:
```bash
docker container create \
--name label \
--label==with-leading-equal-sign \
--label=without-value \
--label=somelabel=somevalue \
--label " = " \
--label=with-quotes-in-value='{"foo"}' \
--label='with"quotes"in-key=test' \
busybox
invalid argument "=with-leading-equal-sign" for "-l, --label" flag: invalid label format: "=with-leading-equal-sign"
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This patch fixes a bug where labels use the same behavior as `--env`, resulting
in a value to be copied from environment variables with the same name as the
label if no value is set (i.e. a simple key, no `=` sign, no value).
An earlier pull request addressed similar cases for `docker run`;
2b17f4c8a8, but this did not address the
same situation for (e.g.) `docker service create`.
Digging in history for this bug, I found that use of the `ValidateEnv`
function for labels was added in the original implementation of the labels feature in
abb5e9a077 (diff-ae476143d40e21ac0918630f7365ed3cR34)
However, the design never intended it to expand environment variables,
and use of this function was either due to either a "copy/paste" of the
equivalent `--env` flags, or a misunderstanding (the name `ValidateEnv` does
not communicate that it also expands environment variables), and the existing
`ValidateLabel` was designed for _engine_ labels (which required a value to
be set).
Following the initial implementation, other parts of the code followed
the same (incorrect) approach, therefore leading the bug to be introduced
in services as well.
This patch:
- updates the `ValidateLabel` to match the expected validation
rules (this function is no longer used since 31dc5c0a9a),
and the daemon has its own implementation)
- corrects various locations in the code where `ValidateEnv` was used instead of `ValidateLabel`.
Before this patch:
```bash
export SOME_ENV_VAR=I_AM_SOME_ENV_VAR
docker service create --label SOME_ENV_VAR --tty --name test busybox
docker service inspect --format '{{json .Spec.Labels}}' test
{"SOME_ENV_VAR":"I_AM_SOME_ENV_VAR"}
```
After this patch:
```bash
export SOME_ENV_VAR=I_AM_SOME_ENV_VAR
docker service create --label SOME_ENV_VAR --tty --name test busybox
docker container inspect --format '{{json .Config.Labels}}' test
{"SOME_ENV_VAR":""}
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This maps the `--template-driver` flag on secret and config creation.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The warning, printed before running `docker system prune` was printing the
filters in JSON format.
This patch attempts to make the output human readable;
- updating the code, and template to print filters individually
- reducing the indentation (which was quite deep)
Before this patch was applied;
```
docker system prune --filter until=24h --filter label=hello-world --filter label!=foo=bar --filter label=bar=baz
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
- Elements to be pruned will be filtered with:
- label={"label":{"bar=baz":true,"hello-world":true},"label!":{"foo=bar":true},"until":{"24h":true}}
Are you sure you want to continue? [y/N]
```
With this patch applied;
```
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
Items to be pruned will be filtered with:
- label!=foo=bar
- label!=never=remove-me
- label=bar=baz
- label=hello-world
- label=remove=me
- until=24h
Are you sure you want to continue? [y/N]
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The warning, printed before runing docker system prune was missing any filter
that was set in the configuration file. In addition, the warning prefixes the
filters with `label=`, which is no longer accurate, now that the prune command
also supports "until" as a filter.
Before this change, only the filters set on the command-line were shown,
and any filter set in the configuration file was missing;
```
mkdir -p ./test-config
echo '{"pruneFilters": ["label!=never=remove-me", "label=remove=me"]}' > test-config/config.json
docker --config=./test-config system prune --filter until=24h --filter label=hello-world --filter label!=foo=bar --filter label=bar=baz
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
- Elements to be pruned will be filtered with:
- label={"label":{"bar=baz":true,"hello-world":true},"label!":{"foo=bar":true},"until":{"24h":true}}
Are you sure you want to continue? [y/N]
```
With this patch applied, both options from the commandline and options set
in the configuration file are shown;
```
mkdir -p ./test-config
echo '{"pruneFilters": ["label!=never=remove-me", "label=remove=me"]}' > test-config/config.json
docker --config=./test-config system prune --filter until=24h --filter label=hello-world --filter label!=foo=bar --filter label=bar=baz
WARNING! This will remove:
- all stopped containers
- all networks not used by at least one container
- all dangling images
- all dangling build cache
- Elements to be pruned will be filtered with:
- filter={"label":{"bar=baz":true,"hello-world":true,"remove=me":true},"label!":{"foo=bar":true,"never=remove-me":true},"until":{"24h":true}}
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
- when using "--context default" parameter
- when printing the list of contexts
- when exporting the default context to a tarball
Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
(+1 squashed commit)
Squashed commits:
[20670495] Fix CLI initialization for the `docker stack deploy --help` command and ensure that the dockerCli.CurrentContext() always returns a non empty context name (default as a fallback)
Remove now obsolete code handling empty string context name
Minor code cleanup
Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
This makes things more idempotent, rather than relying on undoing the
interspersed settings.
Note that the underlying `Flag`s remain shared, it's just the `FlagSet` which
is duplicated.
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>
This happens on Windows when dialing a named pipe (a path which is used by CLI
plugins), in that case some debugging shows:
DEBU[0000] conn is a *winio.win32MessageBytePipe
DEBU[0000] conn is a halfReadCloser: false
DEBU[0000] conn is a halfWriteCloser: true
the raw stream connection does not implement halfCloser
In such cases we can simply wrap with a nop function since closing for read
isn't too critical.
Signed-off-by: Ian Campbell <ijc@docker.com>
Setting `Setsid` is needed for SSH connection helper with `ProxyCommand`
config, so as to detach TTY.
e.g.
$ cat ~/.ssh/config
Host foo
Hostname foo
ProxyCommand ssh -W %h:%p bastion
$ DOCKER_HOST=ssh://foo docker run -it --rm alpine
/ #
Fix#1707
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
After switching to Go 1.12, the format-string causes an error;
```
=== Errors
cli/config/config_test.go:154:3: Fatalf format %q has arg config of wrong type *github.com/docker/cli/cli/config/configfile.ConfigFile
cli/config/config_test.go:217:3: Fatalf format %q has arg config of wrong type *github.com/docker/cli/cli/config/configfile.ConfigFile
cli/config/config_test.go:253:3: Fatalf format %q has arg config of wrong type *github.com/docker/cli/cli/config/configfile.ConfigFile
cli/config/config_test.go:288:3: Fatalf format %q has arg config of wrong type *github.com/docker/cli/cli/config/configfile.ConfigFile
cli/config/config_test.go:435:3: Fatalf format %q has arg config of wrong type *github.com/docker/cli/cli/config/configfile.ConfigFile
cli/config/config_test.go:448:3: Fatalf format %q has arg config of wrong type *github.com/docker/cli/cli/config/configfile.ConfigFile
DONE 1115 tests, 2 skipped, 6 errors in 215.984s
make: *** [Makefile:22: test-coverage] Error 2
Exited with code 2
```
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `conn` here is `*winio.win32MessageBytePipe` which does not have a
`CloseRead` method (it does have `CloseWrite`) resulting in:
docker@WIN-NUC0 C:\Users\docker>.\docker-windows-amd64.exe system dial-stdio
the raw stream connection does not implement halfCloser
Also disable the path which uses this for cli-plugins on Windows.
Signed-off-by: Ian Campbell <ijc@docker.com>
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>
Sebastiaan van Stijn
Ian Campbell
Silvin Lubecki
Goksu Toprak
Tibor Vass
Tõnis Tiigi
Sebastiaan van Stijn
Simon Ferquel
Tibor Vass
Daniel Hiltgen
Drew Erny
Mårten Cassel
Sune Keller
Silvin Lubecki
Abhinandan Prativadi
Nick Adcock
David Scott
Nao YONASHIRO
Akihiro Suda
Lifubang
Kir Kolyshkin
Sunny
Vincent Demeester
Stephane Jeandeaux
Jean-Christophe Sirot
Elliot Luo
Ryan Zhang
Olli Janatuinen
Ulysses Souza
Philipp Schmied
John Howard