java.lang.ClassCastException when upgrading from 2.16.0.Final to 2.16.1.Final

[spolti]

Describe the bug

After upgrading to Quarkus 2.16.1 this issue started to happen:

 Caused by: java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
 	[error]: Build step io.quarkus.kubernetes.deployment.KubernetesProcessor#build threw an exception: java.lang.ClassCastException: class java.util.HashMap cannot be cast to class java.lang.String (java.util.HashMap and java.lang.String are in module java.base of loader 'bootstrap')
 	at io.dekorate.docker.adapter.DockerBuildConfigAdapter.newBuilder(DockerBuildConfigAdapter.java:58)
 	at io.dekorate.docker.config.DockerBuildConfigGenerator.addPropertyConfiguration(DockerBuildConfigGenerator.java:48)
 	at io.dekorate.Session.lambda$addPropertyConfiguration$1(Session.java:167)
 	at io.dekorate.Session.addConfiguration(Session.java:183)
 	at io.dekorate.Session.addPropertyConfiguration(Session.java:167)
 	at io.quarkus.kubernetes.deployment.KubernetesProcessor.lambda$build$2(KubernetesProcessor.java:164)
	at java.base/java.util.Optional.ifPresent(Optional.java:183)
	at io.quarkus.kubernetes.deployment.KubernetesProcessor.build(KubernetesProcessor.java:141)
 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
 	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:829)
 	at org.jboss.threads.JBossThread.run(JBossThread.java:501)

Expected behavior

No issues when upgrading from 2.16.0.Final to 2.16.1.Final

Actual behavior

This seems to be a breaking change that we would not expect to see in a minor release.

How to Reproduce?

No response

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

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

No response

Additional information

No response

[quarkus-bot]

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

[radtriste]

See also https://github.com/kiegroup/kogito-runtimes/pull/2783

[Sgitario]

Can you share the configuration you're using?

[radtriste]

@Sgitario https://github.com/kiegroup/kogito-examples/tree/main/kogito-quarkus-examples/onboarding-example/onboarding-quarkus

[radtriste]

that would be:

quarkus.http.port=8080
quarkus.infinispan-client.hosts=localhost:11222
quarkus.infinispan-client.use-auth=false

# Kubernetes related properties
%minikube.quarkus.kubernetes.deployment-target=minikube
%kubernetes.quarkus.kubernetes.deployment-target=kubernetes
quarkus.container-image.group=kogito
quarkus.container-image.name=onboarding-service
quarkus.container-image.tag=latest
quarkus.kubernetes.labels.onboarding=process

%knative.quarkus.kubernetes.deployment-target=kubernetes
%knative.quarkus.knative.labels.onboarding=process

[geoand]

Looks like a dekotate issue. @Sgitario we should probably add some kind of test in Quarkus to make sure this never happens again

[Sgitario]

We already have tests to cover this scenario.
I could not reproduce this issue when building the Kogito example locally and using Quarkus 2.16.1.Final (I simply tried mvn clean install). Let me know if I need to use something else to reproduce it.

Also, are you adding some properties when running Maven? I could not find any in the Jenkins logs though :/
Quarkus Kubernetes is automatically mapping some properties into Dekorate properties and maybe here is the issue, but I can't be 100% sure.

[geoand]

We certainly have tests, but something is obviously wrong in this case.
It would be nice to add a test once we know that the actual problem is

[Sgitario]

We certainly have tests, but something is obviously wrong in this case. It would be nice to add a test once we know that the actual problem is

Indeed

[radtriste]

command line:

mvn clean install  -s /home/jenkins/workspace/KIE/kogito/main/pullrequest/kogito-runtimes.tests.downstream.kogito-quarkus-examples@tmp/config1980440886206568513tmp -Dmaven.wagon.http.ssl.insecure=true -Dmaven.test.failure.ignore=true -nsu -ntp -fae -e -Dhttp.keepAlive=false -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.ttlSeconds=120 -Dmaven.wagon.http.retryHandler.count=3   dependency:tree  -Dorg.slf4j.simpleLogger.log.org.apache.maven.cli.transfer.Slf4jMavenTransferListener=warn -B

nothing quarkus specific here

Trying to get quick reproducer

[Sgitario]

Thanks

To give more information, the dekorate version is the same for 2.16.0.Final and 2.16.1.Final.
In Quarkus, as far I see, the only difference in the Kubernetes extension between these releases is #30591, which seems related. Though, I don't see how these changes could break your example.

[radtriste]

ok. cannot reproduce as well ...
so seems an issue on CI ...

[spolti]

@radtriste can this be closed?