OpenShift deployment don't generate command when arguments are provided

[michalvavrik]

Describe the bug

When quarkus.openshift.arguments are provided, first one is used as command is not generated. I think the behavior was introduced by #27733, but the PR description says The command may still be generated if the user provides arguments without command.

Expected behavior

One of:

• Behavior is same as in 2.12 - command is generated.
• Documentation correct my expectation; https://quarkus.io/guides/deploying-to-openshift#generating-job-resources does not explain behavior.
• Build fails as no command has been specified.

Actual behavior

Container fails to start as first argument is used to start the app.

Error: container create failed: time="2022-11-23T15:50:25Z" level=error msg="runc create failed: unable to start container process: exec: "ARG1": executable file not found in $PATH"

How to Reproduce?

Reproducer:

Steps to reproduce the behavior:

0. OC - logged in
1. quarkus create app org.acme:openshift-quickstart \ --extension='resteasy-reactive,openshift'
2. cd openshift-quickstart
3. quarkus build -Dquarkus.kubernetes.deploy=true -Dquarkus.kubernetes-client.trust-certs=true -Dquarkus.openshift.arguments="ARG1,ARG2" -Dquarkus.platform.version=2.13.0.Final -DskipTests -DskipITs (NOTE: same happens when you use -Dnative)
4. oc get pod

Alternatively:

1. git clone https://github.com/quarkus-qe/quarkus-test-suite.git
2. cd quarkus-test-suite/lifecycle-application
3. mvn clean verify -Dopenshift -Dit.test=OpenShiftLifecycleApplicationIT (NOTE: same happens when you use -Dnative)
4. oc get pod

Output of uname -a or ver

Linux

Output of java -version

openjdk version "17.0.5" 2022-10-18

GraalVM version (if different from Java)

GraalVM CE 22.3.0

Quarkus version or git rev

2.13.0 +, 2.14, 999-SNAPSHOT

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

Apache Maven 3.8.6

Additional information

No response

[quarkus-bot]

/cc @Sgitario, @geoand, @iocanel

[Sgitario]

This is an issue with the default images "ubi8/openjdk-11" and "ubi8/openjdk-17" (also for the new "ubi9" images).
These images seem to use the first argument when provided on purpose. Though I think this is wrong, let's workaround it by providing the command.
This issue is also happening in Native mode.
Fix #29724