hernanDatgDev opened a new issue, #5207: URL: https://github.com/apache/camel-k/issues/5207
### What happened? Link to Zulip chat: https://camel.zulipchat.com/#narrow/stream/257299-camel-k/topic/Run.20integration.20w.20existing.20native.20image.20.2F.20image.20trait When running an integration with a native image defined explicitly the pod is using the wrong command to start the container and as a result the pod fails to start. Under normal native integration execution (without defining the container image) the pod is started with a command that calls the native executable. For example: ``` - command: - ./camel-k-integration-2.3.0-runner ``` When running an integration in the default jvm mode, the pod command is different. For example ``` - args: ... io.quarkus.bootstrap.runner.QuarkusEntryPoint command: - /bin/sh - -c ``` When running an integration with a native image defined explicitly, the pod tries to start the native app with the default jvm command which does not work. With guidance from the community I tried running the same integration with the native image, also with the JVM trait disabled. This resulted in the pod having no command defined at all, which of course did still not work. There was a brief mention in Zulip for including the starting command to the kit image itself. I personally favor this suggestion however looking for further guidance on the best way to move forward with this issue. ### Steps to reproduce 1. Run any integration in native mode. Save the image generated. 2. Run any other integration (can be the same), and configure the `container.image` trait with the image saved from step 1. ### Relevant log output _No response_ ### Camel K version 2.3.0-SNAPSHOT, 2.1.0 (personal patched version) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@camel.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
