Quarkus: container-image-docker silently fails

[zeljkot]

Describe the bug
If Docker daemon is not available, build finishes with success even if Docker image creation fails. This is big issue in CI environment.

 [INFO] --- quarkus-maven-plugin:1.3.2.Final:build (default) @ asc-api-service ---
 [INFO] Init
 [WARNING] No etcd endpoint configured. Source will be disabled ;_;
 [INFO] Initialization finished
 [WARNING] [io.quarkus.container.image.docker.deployment.DockerBuild] Could not connect to docker daemon!
 [WARNING] [io.quarkus.container.image.docker.deployment.DockerBuild] Could not connect to docker daemon!
 [INFO] [org.jboss.threads] JBoss Threads version 3.0.1.Final
 [INFO] [io.quarkus.smallrye-reactive-messaging.deployment.processor] Metric is disabled - vetoing the MetricDecorator
 [INFO] Initializing dekorate session.
 [INFO] [org.hibernate.Version] HHH000412: Hibernate ORM core version 5.4.14.Final
 [INFO] Default s2i build generator....
 [INFO] Registering s2i handler!
 [INFO] Registering s2i handler!
 [INFO] Generating manifests.
 [INFO] Processing kubernetes configuration.
 [INFO] Processing openshift configuration.
 [INFO] Processing s2i configuration.
 [INFO] Closing dekorate session.
 [INFO] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Building thin jar: /builds/myproject/mymodule/target/service-runner.jar
 [INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 3899ms
 [INFO] ------------------------------------------------------------------------
 [INFO] BUILD SUCCESS
 [INFO] ------------------------------------------------------------------------

No Docker image was generated.

Expected behavior
(Describe the expected behavior clearly and concisely.)
Build should fail if image cannot be created.

Actual behavior
(Describe the actual behavior clearly and concisely.)
Build finishes successfully, no image was created.

To Reproduce
Steps to reproduce the behavior:

1. Kill docker daemon
2. mvn package

Configuration

# Add your application.properties here, if applicable.

Screenshots
(If applicable, add screenshots to help explain your problem.)

Environment (please complete the following information):

• Output of uname -a or ver:
• Output of java -version:
• GraalVM version (if different from Java):
• Quarkus version or git rev: 1.3.2.Final
• Build tool (ie. output of mvnw --version or gradlew --version):

Additional context
(Add any other context about the problem here.)

[zeljkot]

After checking the source code, I found out that message is misleading: a warning will be shown if there is no Docker on a host (no binaries), not just if it cannot connect to the daemon.

[gsmet]

/cc @iocanel @geoand

[geoand]

Good catch. I'll fix it soon.

[geoand]

I opened #8527.

In there I haven't made the build fail (which I don't think is the proper behavior), but I instead improved the error messages.

[zeljkot]

Build should fail because an artifact is not produced. I spent couple of hours trying to figure out why GitLab CI does not work as expected, trying to deploy nothing or old image to Kubernetes cluster with Helm. So many layers to debug.

You would fail the build if you could not produce JAR or uploaded it repo. The same should apply to image. Please make it fail.

[geoand]

Although I don't agree, I could be persuaded to do it (or pehaps make it configurable).

@gastaldi @maxandersen @Ladicek WDYT?

[gastaldi]

Correct me if I'm wrong but, considering that the resulting artifact of the build is an image and that is not produced in this case I agree with @zeljkot that the build must fail.

I don't think this behavior needs to be configurable, unless there is an option to skip the image generation completely.

[geoand]

The image generation is opt-in, so I guess it does make sense to fail even when it's not our fault.

I'll wait for more feedback however before changing the behavior (which would be a breaking change BTW, which is why I suggested it being configurable).

[gsmet]

I think it should fail too if the user is expecting an image to be produced and the image fails to be produced.

And let's not add too many configuration knobs. We agreed we would break things from time to time if it was for the better. Looks like it's the case here?

Moreover, I don't see a user happy that the build hasn't failed while the expected image (you said it was opt-in?) hadn't been produced.

[geoand]

Point taken, I'll update the PR.

PR updated