DockerBuildImage fails with Docker 17.05

[dmitrygusev]

Version 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

[KostyaSha]

Could you check how this logic is handled in docker CLI sources? We usually implement the same.

[dmitrygusev]

Here's the change in builder:

[KostyaSha]

and how we could do it in backward compatible manner?..

…

On 18 Apr 2017 11:58 a.m., "Dmitry Gusev" ***@***.***> wrote: Here's the change <moby/moby@17.03.x...17.05.x#diff-8145809cef82b62e31a5fce12cd7240aL307> in builder: [image: Added 'Successfully tagged'] <https://cloud.githubusercontent.com/assets/76579/25122539/f5726a48-242d-11e7-85f1-8096c715b5a3.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#830 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAOIu_AfiMpNPmmIZIguxS8V51MFphq8ks5rxHstgaJpZM4M_TMn> .

[dmitrygusev]

If I understand this right, the simplest way is probably to keep two latest lines of the output in the BuildImageResultCallback.java:31.

And when time comes pick one of the two that matches the "Successfully built" pattern.

What do you think?

[KostyaSha]

I think that it will fail on non-17 versions that we can't accept. And it seems that you found only daemon side, while we should check CLI code and how they handle it.

[dmitrygusev]

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?

[dmitrygusev]

@KostyaSha anything else I can do to get the proposed fix merged?

[cdancy]

@KostyaSha any chance we could get a release with this change in place? Running into more than a few hiccups because of this...

[KostyaSha]

Yes, stuck with swarm tests. Also almost ready to do swarm releases... But tests...

[KostyaSha]

Btw, does this all work fine with multi-sage builds?

[cdancy]

No issues that I've found thus far. What are your concerns and/or what are you thinking?

[KostyaSha]

End of build marker is xXX built/tagged multi-stage do multiple builds...

[docwhat]

Updated link to the change in docker (now moby)

[docwhat]

Also, is this a problem in the dockerd service or the docker client? Can this be worked around by using an older docker client (but leaving the dockerd at the latest version)?

[cdancy]

@KostyaSha FYI: running our gradle-docker-plugin integration tests against your 3.0.10-SNAPSHOT version does indeed solve our tests breaking.