DockerBuildImage fails with Docker 17.05
See original GitHub issueVersion 17.05.0-ce-rc1-mac8 (16582) Channel: edge 73d01bb48e
Fails with NPE (see below) although docker build itself succeeded:
Step 12/12 : CMD bundle exec rake db:migrate && bundle exec rails s
---> Using cache
---> b7c2febdf592
Successfully built b7c2febdf592
Successfully tagged app:b2279a4
As I understand the reason is that last line in the build output is now not “Successfully built”, but “Successfully tagged”.
Stacktrace:
Caused by: com.github.dockerjava.api.exception.DockerClientException: Could not build image: null
at com.github.dockerjava.core.command.BuildImageResultCallback.getImageId(BuildImageResultCallback.java:71)
at com.github.dockerjava.core.command.BuildImageResultCallback.awaitImageId(BuildImageResultCallback.java:48)
at java_lang_reflect_Method$invoke.call(Unknown Source)
at java_lang_reflect_Method$invoke.call(Unknown Source)
at com.bmuschko.gradle.docker.utils.DockerThreadContextClassLoader$_createPrintStreamProxyCallback_closure12.doCall(DockerThreadContextClassLoader.groovy:577)
at com.sun.proxy.$Proxy160.invoke(Unknown Source)
at com.github.dockerjava.core.command.BuildImageResultCallback$$EnhancerByCGLIB$$994b76df.awaitImageId(<generated>)
at com.github.dockerjava.core.command.BuildImageResultCallback$$EnhancerByCGLIB$$994b76df$awaitImageId.call(Unknown Source)
at com.github.dockerjava.core.command.BuildImageResultCallback$$EnhancerByCGLIB$$48a3fefd$awaitImageId.call(Unknown Source)
at com.bmuschko.gradle.docker.tasks.image.DockerBuildImage.runRemoteCommand(DockerBuildImage.groovy:127)
at com.bmuschko.gradle.docker.tasks.AbstractDockerRemoteApiTask$_runReactiveStream_closure1.doCall(AbstractDockerRemoteApiTask.groovy:57)
at com.bmuschko.gradle.docker.utils.DockerThreadContextClassLoader.withClasspath(DockerThreadContextClassLoader.groovy:54)
at com.bmuschko.gradle.docker.utils.ThreadContextClassLoader$withClasspath.call(Unknown Source)
at com.bmuschko.gradle.docker.tasks.AbstractDockerRemoteApiTask.runInDockerClassPath(AbstractDockerRemoteApiTask.groovy:62)
at com.bmuschko.gradle.docker.tasks.AbstractDockerRemoteApiTask$runInDockerClassPath.callCurrent(Unknown Source)
at com.bmuschko.gradle.docker.tasks.AbstractDockerRemoteApiTask.runReactiveStream(AbstractDockerRemoteApiTask.groovy:56)
at com.bmuschko.gradle.docker.tasks.AbstractReactiveStreamsTask.start(AbstractReactiveStreamsTask.groovy:50)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.doExecute(DefaultTaskClassInfoStore.java:141)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:134)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:123)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:632)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:615)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:95)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:76)
... 70 more
Issue Analytics
- State:
- Created 6 years ago
- Comments:15 (13 by maintainers)
Top Results From Across the Web
Docker Engine 17.05 release notes
Docker Engine 17.05 release notes ... Display created tags on successful docker build #32077; Cleanup compose convert error messages #32087 ...
Read more >Multi-stage builds - Docker Documentation
This is failure-prone and hard to maintain. It's easy to insert another command and ... Multi-stage build syntax was introduced in Docker Engine...
Read more >Docker Engine release notes - Docker Documentation
This release of Docker Engine comes with a fix for a low-severity security issue, some minor bug fixes, and updated versions of Docker...
Read more >Workarounds for common problems - Docker Documentation
The conflict typically occurs after a Windows update and manifests as an error response from the Docker daemon and a Docker Desktop start...
Read more >Deprecated Engine Features - Docker Documentation
Note that this fallback only addresses failures on docker pull . ... Docker 17.05 added an optional --detach=false option to make the docker...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Why would it fail if it’s an additive change? Previous versions will still be able to find the “Successfully built” string in the last
BuildResponseItem
. New versions will find it in a line before the last.I’m not sure I understand what you mean by saying “how Docker CLI handles this”? I don’t think Docker CLI interprets the output anyhow, it just prints it to the stdout. And the way docker-java handles it – it just reads everything from that output stream and takes the last line. Or am I wrong here?
Btw, does this all work fine with multi-sage builds?