Deploying with quarkus cli from a 'cleaned' project doesn't perform previoius lifecycle phases

[aureamunoz]

Describe the bug

The quarkus deploy command isn't generating and compiling the code. Then the application endpoints are not accessibles when deploy the project with the --clean option.

Expected behavior

I would expect the lifecycle phases are executed sequentially to complete the lifecycle. This means that when the quarkus deploycommand is used,it will generate the code, then will try to compile the sources, run tests, package the binaries and then deploy the package to the cluster.

Actual behavior

quarkus deploy just clears out the existing classes and then run the deploy phase:

[INFO] Scanning for projects...
[INFO] 
[INFO] ----------------------< org.acme:getting-started >----------------------
[INFO] Building getting-started 1.0.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ getting-started ---
[INFO] Deleting /Users/auri/Code/getting-started-on-quarkus-demo/target
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-cli) @ getting-started ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  0.648 s
[INFO] Finished at: 2023-05-26T13:43:13+02:00
[INFO] ------------------------------------------------------------------------
[INFO] Scanning for projects...
[INFO] 
[INFO] ----------------------< org.acme:getting-started >----------------------
[INFO] Building getting-started 1.0.0-SNAPSHOT
[INFO] --------------------------------[ jar ]---------------------------------
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ getting-started ---
[INFO] Deleting /Users/auri/Code/getting-started-on-quarkus-demo/target
[INFO] 
[INFO] --- quarkus-maven-plugin:3.0.3.Final:deploy (default-cli) @ getting-started ---
[WARNING] [io.quarkus.hibernate.orm.deployment.HibernateOrmProcessor] Hibernate ORM is disabled because no JPA entities were found
[INFO] [io.quarkus.container.image.openshift.deployment.OpenshiftProcessor] Starting (in-cluster) container image build for jar using: BINARY on server: https://api.sandbox-m3.1530.p1.openshiftapps.com:6443/ in namespace:amunozhe-dev.
[INFO] [io.quarkus.

Note the WARNING message: Hibernate ORM is disabled because no JPA entities were foundwhile I have at least one @entity class.

How to Reproduce?

Reproducer:
Be sure to be connected to a (OpenShift) cluster.

1 - unzip getting-started.zip
2 - quarkus deploy openshift --clean --image-build -Dquarkus.openshift.route.expose=true

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

3.0.4.Final

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

No response

Additional information

Apache Maven 3.8.8 (4c87b05d9aedce574290d1acc98575ed5eb6cd39)
Maven home: /Users/auri/.sdkman/candidates/maven/current
Java version: 17.0.5, vendor: GraalVM Community, runtime: /Users/auri/.sdkman/candidates/java/22.3.r17-grl
Default locale: es_ES, platform encoding: UTF-8
OS name: "mac os x", version: "13.3.1", arch: "aarch64", family: "mac"

getting-started.zip

[quarkus-bot]

/cc @ebullient (cli), @geoand (openshift), @iocanel (openshift), @maxandersen (cli)

[ebullient]

my understanding is that quarkus deploy is not a build step as it is in maven, it is an active/action step once something has been built.

It's possible that --clean as an option should be hidden/ignored if this is the case.

@iocanel .. can you clarify intent here?

[iocanel]

quarkus deploy is a cli command that delegates to the mvn quarkus:deploy it is not intended to go for a full build.

Of course, cleaning may affect the generated manifests (e.g. application.properties will be ignored in a clean project). For this reason we do behind the scenes a resources:resources. In your case however, it seems that container image is also getting affected, so we might need to switch that with package.

One things I need to check is why a full build is not triggered indirectly given that container image extensions do depend on the ArtifactResultBuildItem (the jar) for container image builds.