Commit Graph

6 Commits

Author SHA1 Message Date
Sebastiaan van Stijn 2c0e93063b
bump gotest.tools v3.0.1 for compatibility with Go 1.14
full diff: https://github.com/gotestyourself/gotest.tools/compare/v2.3.0...v3.0.1

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2020-02-23 00:28:55 +01:00
Silvin Lubecki cfd5b16ae0
Merge pull request #1745 from ijc/disable-dial-stdio-for-plugins
cli-plugins: disable use of dial-stdio
2019-03-18 12:29:41 +01:00
Ian Campbell ff2ed6efa8 cli-plugins: disable use of dial-stdio
Since #1654 so far we've had problems with it not working on Windows (npipe
lacked the `CloseRead` method) and problems with using tcp with tls (the tls
connection also lacks `CloseRead`). Both of these were workedaround in #1718
which added a nop `CloseRead` method.

However I am now seeing hangs (on Windows) where the `system dial-stdio`
subprocess is not exiting (I'm unsure why so far).

I think the 3rd problem found with this is an indication that `dial-stdio` is
not quite ready for wider use outside of its initial usecase (support for
`ssh://` URLs to connect to remote daemons).

This change simply disables the `dial-stdio` path for all plugins. However
rather than completely reverting 891b3d953e ("cli-plugins: use `docker system
dial-stdio` to call the daemon") I've just disabled the functionality at the
point of use and left in a trap door environment variable so that those who
want to experiment with this mode (and perhaps fully debug it) have an easier
path do doing so.

The e2e test for this case is disabled unless the trap door envvar is set. I
also renamed the test to clarify that it is about cli plugins.

Signed-off-by: Ian Campbell <ijc@docker.com>
2019-03-18 10:58:51 +00:00
Jean-Christophe Sirot 37fcaf7a29 Resolve the docker Endpoint even if the client already exists. In that case the `TestDialStdio` e2e test had to be modified: the `--tls` option triggers an error since the endpoint resolution tries to read the `${DOCKER_CERT_PATH}/ca.pem` file which does not exist.
Signed-off-by: Jean-Christophe Sirot <jean-christophe.sirot@docker.com>
2019-03-13 14:18:41 +01:00
Akihiro Suda dbe7afbd04 connhelper: export functions for other projects
Exposed functions are planned to be used by `buildctl`:
https://github.com/moby/buildkit/issues/769

Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
2019-03-02 21:11:49 +09:00
Ian Campbell 891b3d953e cli-plugins: use `docker system dial-stdio` to call the daemon
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>
2019-02-18 11:53:37 +00:00