container-image extension running with kubernetes extension

[mikethecalamity]

Describe the bug

When using the kubernetes extension, it seems like the container-image extension is also running. I don't explicitly have the container-image extension in my build.gradle. And it causes the error below.

I can workaround this issue by adding version = "0.0.0" to my build.gradle, but it is concerning that another extension seems to be running without my knowledge.

Expected behavior

Successful build without the container-image extension

Actual behavior

Execution failed for task ':service:quarkusBuild'.
> io.quarkus.builder.BuildException: Build failure: Build failed due to errors
  	[error]: Build step io.quarkus.container.image.deployment.ContainerImageProcessor#publishImageInfo threw an exception: java.lang.IllegalArgumentException: The supplied container-image tag '<<unset>>' is invalid
  	at io.quarkus.container.image.deployment.ContainerImageProcessor.publishImageInfo(ContainerImageProcessor.java:96)
  	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
  	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
  	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
  	at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:909)
  	at io.quarkus.builder.BuildContext.run(BuildContext.java:281)
  	at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
  	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2449)
  	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1478)
  	at java.base/java.lang.Thread.run(Thread.java:833)
  	at org.jboss.threads.JBossThread.run(JBossThread.java:501)

How to Reproduce?

Reproducer:

1. Clone https://github.com/mikethecalamity/quarkus-test
2. ./gradlew -p apps service1:build

Output of uname -a or ver

No response

Output of java -version

17

GraalVM version (if different from Java)

No response

Quarkus version or git rev

2.15.3

Build tool (ie. output of mvnw --version or gradlew --version)

Gradle 7.5.1

Additional information

No response

[quarkus-bot]

/cc @Sgitario (kubernetes), @geoand (kubernetes), @iocanel (kubernetes)

[geoand]

Can you attach a sample application that exhibits this behavior please?

[mikethecalamity]

Added reproducer above.

[iocanel]

I have been working on #30309 and I have encountered myself quite a few issues when it comes to generating manifests but without using a container image extension, but it's the first time I see this one.

[geoand]

Unfortunately I can't run the project:

Exception in thread "main" java.net.UnknownHostException: nexus-master.beast.us.lmco.com

[mikethecalamity]

@geoand The reproducer is fixed now

[Sgitario]

The container-image dependency is brought by the kubernetes extension (see here).

This works in a Maven setup because the application version is always set. However, not it's the case for Gradle. When the application version is not set, Quarkus sets << unset >> by default.

Moreover, the default latest value in here is never used.

Therefore, we should fix this issue by:

• Not doing anything in publishImageInfo if there is no implementations configured
• And check that the application version is << unset >> and if so, use latest

[geoand]

I would say we should use latest

[Sgitario]

Do you mean that we should still run the publishImageInfo method even when there are no container image implementations configured?

[geoand]

Which method is that?

[Sgitario]

quarkus/extensions/container-image/deployment/src/main/java/io/quarkus/container/image/deployment/ContainerImageProcessor.java

Line 46 in 17d010d

public void publishImageInfo(ApplicationInfoBuildItem app,

[geoand]

Yeah, I think we should continue to execute that. My guess is that pieces will break if we don't

…

On Wed, Jan 25, 2023, 08:22 Jose Carvajal ***@***.***> wrote: https://github.com/quarkusio/quarkus/blob/17d010d354a8ad7d1cad89506b5a6ce5ea1c444c/extensions/container-image/deployment/src/main/java/io/quarkus/container/image/deployment/ContainerImageProcessor.java#L46 — Reply to this email directly, view it on GitHub <#30559 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBMDPZRPVD65W3RYY5WWNDWUDBBPANCNFSM6AAAAAAUECNPZI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Sgitario]

Yeah, I think we should continue to execute that. My guess is that pieces will break if we don't
…
On Wed, Jan 25, 2023, 08:22 Jose Carvajal @.> wrote:

quarkus/extensions/container-image/deployment/src/main/java/io/quarkus/container/image/deployment/ContainerImageProcessor.java

Line 46 in 17d010d

public void publishImageInfo(ApplicationInfoBuildItem app,

— Reply to this email directly, view it on GitHub <#30559 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBMDPZRPVD65W3RYY5WWNDWUDBBPANCNFSM6AAAAAAUECNPZI . You are receiving this because you were mentioned.Message ID: @.>

Indeed, if we don't execute that, the container image in the generated Deployment is wrong. Then, I will only proceed with this change:

• check that the application version is << unset >> and if so, use latest

[geoand]

👍🏼

[mikethecalamity]

Is there any concern with future breakages because it's running unknowingly? Since it's being pulled in by the kubernetes extension and a dev is not expecting it to run, the necessary configs may be missing and unexpected behaviors may occur. Just a thought.

[Sgitario]

Having the container image extension as part of the Kubernetes extension is expected since we use it to populate the correct container image in the generated manifests.

Fix #30591