This test, and probably other tests that spin up new daemons, use the default configuration, which means they tried to setup a daemon/client to use; see
- a
unix:// socket for exposing the API
- use
--storage-driver=overlay2
Both of those won't work on Windows, which means we're currently skipping those tests.
We should investigate if we can make those tests work on Windows as well, either by spinning up a daemon with different settings, or (depending on the test) by re-using a daemon for those tests. We don't run these tests in parallel, so re-using a daemon could be an option (if we properly clean-up state after each test).
There's some things to consider though;
- the Linux daemons
docker load a busybox image (and some optionally some other images) to be used for starting containers used during the tests. While this can be done fast (couple of seconds) on Linux, loading an image on Windows takes minutes, so is not a solution if we want to spin op a new daemon.
- because of the above, we can start with tests that don't require containers to be created
- re-use a daemon for other tests (see the paragraph higher up)
Some details about the test-failures can be found in #40155;
https://ci.docker.com/public/blue/rest/organizations/jenkins/pipelines/moby/branches/PR-40154/runs/5/nodes/52/log/?start=0
00:14:14.623 --- FAIL: TestInfoDebug (0.01s)
00:14:14.623 info_test.go:75: [dbe75bf7729f3] failed to start daemon with arguments [--containerd /var/run/docker/containerd/containerd.sock --data-root D:\gopath\src\github.com\docker\docker\bundles\tmp\TestInfoDebug\dbe75bf7729f3\root --exec-root C:\windows\TEMP\dxr\dbe75bf7729f3 --pidfile D:\gopath\src\github.com\docker\docker\bundles\tmp\TestInfoDebug\dbe75bf7729f3\docker.pid --userland-proxy=true --containerd-namespace dbe75bf7729f3 --containerd-plugins-namespace dbe75bf7729f3p --host unix://C:\windows\TEMP\docker-integration\dbe75bf7729f3.sock --storage-driver overlay2 --debug] : protocol not available
00:14:14.623 === RUN TestInfoInsecureRegistries
00:14:14.623 --- FAIL: TestInfoInsecureRegistries (0.00s)
00:14:14.623 info_test.go:100: [d3c745c16a39c] failed to start daemon with arguments [--containerd /var/run/docker/containerd/containerd.sock --data-root D:\gopath\src\github.com\docker\docker\bundles\tmp\TestInfoInsecureRegistries\d3c745c16a39c\root --exec-root C:\windows\TEMP\dxr\d3c745c16a39c --pidfile D:\gopath\src\github.com\docker\docker\bundles\tmp\TestInfoInsecureRegistries\d3c745c16a39c\docker.pid --userland-proxy=true --containerd-namespace d3c745c16a39c --containerd-plugins-namespace d3c745c16a39cp --host unix://C:\windows\TEMP\docker-integration\d3c745c16a39c.sock --debug --storage-driver overlay2 --insecure-registry=192.168.1.0/24 --insecure-registry=insecurehost.com:5000] : protocol not available
00:14:14.623 === RUN TestInfoRegistryMirrors
00:14:14.623 --- FAIL: TestInfoRegistryMirrors (0.01s)
00:14:14.623 info_test.go:124: [d277126ad0515] failed to start daemon with arguments [--containerd /var/run/docker/containerd/containerd.sock --data-root D:\gopath\src\github.com\docker\docker\bundles\tmp\TestInfoRegistryMirrors\d277126ad0515\root --exec-root C:\windows\TEMP\dxr\d277126ad0515 --pidfile D:\gopath\src\github.com\docker\docker\bundles\tmp\TestInfoRegistryMirrors\d277126ad0515\docker.pid --userland-proxy=true --containerd-namespace d277126ad0515 --containerd-plugins-namespace d277126ad0515p --host unix://C:\windows\TEMP\docker-integration\d277126ad0515.sock --debug --storage-driver overlay2 --registry-mirror=https://192.168.1.2 --registry-mirror=http://registry.mirror.com:5000] : protocol not available
This test, and probably other tests that spin up new daemons, use the default configuration, which means they tried to setup a daemon/client to use; see
unix://socket for exposing the API--storage-driver=overlay2Both of those won't work on Windows, which means we're currently skipping those tests.
We should investigate if we can make those tests work on Windows as well, either by spinning up a daemon with different settings, or (depending on the test) by re-using a daemon for those tests. We don't run these tests in parallel, so re-using a daemon could be an option (if we properly clean-up state after each test).
There's some things to consider though;
docker loada busybox image (and some optionally some other images) to be used for starting containers used during the tests. While this can be done fast (couple of seconds) on Linux, loading an image on Windows takes minutes, so is not a solution if we want to spin op a new daemon.Some details about the test-failures can be found in #40155;
https://ci.docker.com/public/blue/rest/organizations/jenkins/pipelines/moby/branches/PR-40154/runs/5/nodes/52/log/?start=0