Our team uses the plugins/docker image to build and publish docker images. We have always used the latest version, by default, until this morning it broke with the following error:
You might also find it helpful to use the tagged plugin images in your yaml instead of using latest. This would protect you from breaking changes, should they occur. https://hub.docker.com/r/plugins/docker/tags/
It could be the combination with our Drone version (0.7.0), since it looks like you are using a different version. I also have pull: true, so I know I always get the latest version of the plugins/docker image. When I set the image to plugins/docker:17.05, everything works as expected.
Also, are you publishing to a private Docker Hub repo?
Plugins are version agnostic, and would not behave differently in 0.7 vs 0.8. I recommend using the debug guide and setting debug: true to surface additional information.
The only difference between 17.05 and latest is the Docker version. The latest tag uses 17.10 and the inability to login often indicates the Docker daemon could not start (debug: true would surface this). This would generally indicate an issue with the host machine configuration, or perhaps a bug in the official docker:dind-17.10 container.
/usr/local/bin/dockerd -g /var/lib/docker
0s2time=“2017-11-30T20:08:13Z” level=warning msg=“the “-g / --graph” flag is deprecated. Please use “–data-root” instead”
0s3time=“2017-11-30T20:08:13.843130669Z” level=warning msg=“could not change group /var/run/docker.sock to docker: group docker not found”
0s4time=“2017-11-30T20:08:13.847144504Z” level=info msg=“libcontainerd: new containerd process, pid: 27”
0s5time=“2017-11-30T20:08:14.908938672Z” level=info msg=“Graph migration to content-addressability took 0.00 seconds”
1s6time=“2017-11-30T20:08:14.909593108Z” level=warning msg=“Your kernel does not support cgroup rt period”
1s7time=“2017-11-30T20:08:14.909630938Z” level=warning msg=“Your kernel does not support cgroup rt runtime”
1s8time=“2017-11-30T20:08:14.910637470Z” level=info msg=“Loading containers: start.”
1s9time=“2017-11-30T20:08:14.913703911Z” level=warning msg=“Running modprobe bridge br_netfilter failed with message: modprobe: can’t change directory to ‘/lib/modules’: No such file or directory\n, error: exit status 1”
1s10time=“2017-11-30T20:08:14.915405630Z” level=warning msg=“Running modprobe nf_nat failed with message: modprobe: can't change directory to '/lib/modules': No such file or directory, error: exit status 1”
1s11time=“2017-11-30T20:08:14.916957160Z” level=warning msg=“Running modprobe xt_conntrack failed with message: modprobe: can't change directory to '/lib/modules': No such file or directory, error: exit status 1”
1s12time=“2017-11-30T20:08:15.012007145Z” level=info msg=“Default bridge (docker0) is assigned with an IP address 172.18.0.0/16. Daemon option --bip can be used to set a preferred IP address”
1s13time=“2017-11-30T20:08:15.078701793Z” level=info msg=“Loading containers: done.”
1s14time=“2017-11-30T20:08:15.127987206Z” level=info msg=“Daemon has completed initialization”
1s15time=“2017-11-30T20:08:15.128061978Z” level=info msg=“Docker daemon” commit=89658be graphdriver=overlay2 version=17.05.0-ce
1s16time=“2017-11-30T20:08:15.150978019Z” level=info msg=“API listen on /var/run/docker.sock”
1s17+ /usr/local/bin/docker version
etc…
I am not sure this is the case, we would see + /usr/local/bin/docker version in the logs, which I do not see in the screenshot. This would tell me the plugin did not get that far. The version is only printed after the login, which seems to be the point of failure.
I cannot repeat any errors with the plugin, and we only bumped the Docker version. I do not have enough information (at least not yet) to reproduce or to conclude there is a problem with the plugin itself.
If you think the plugin is broken, you should be able to run it in isolation to confirm. Instructions for running the plugin directly can be found here: https://github.com/drone-plugins/drone-docker#usage
Just wanted to report that we did have this issue reported to me at work today and I was able to track down why Docker was exiting with status 125.
We are still running Drone 0.5 and with the update of the plugin to DinD 17.10 we had this failure happen. I’ve pinpointed that this issue coreletae with the deprecation of the docker login -e option. By default, the plugin will use the -e options if the email secret is set (in our case it was setup via the DOCKER_EMAIL secret), see https://github.com/drone-plugins/drone-docker/blob/master/docker.go#L151-L153. By removing the secret for our database we were able to fix the issue.
I am pretty sure that this is whatt is causing us issue, as I have also checked the return code for Docker on 17.11 locally and when trying to log with docker login -u me -e me@provid.er -p mypassword my.registry.com Docker exits with the specific code 125 with the following error message: unknown shorthand flag: 'e' in -e.
Hope this helps.
PS: I was going to create an issue on Github when I was redirected here and found this thread.
