When using test framework without quarkus-openshift, it fails with weird error

[llowinge]

When we use app-metadata + common dependency (without quarkus-openshift dependency) and run mvn verify, it fails with not really helpful error:

[ERROR] Failed to execute goal io.quarkus:quarkus-maven-plugin:1.12.0.Final:build (build) on project camel-quarkus-examples-rest-json: Failed to build quarkus application: io.quarkus.builder.ChainBuildException: No producers for required item class io.quarkus.container.spi.ContainerImageInfoBuildItem -> [Help 1]

[Ladicek]

If I remember correctly, the original assumption was that the test module would either use quarkus-openshift, or a combination of quarkus-kubernetes + quarkus-container-image-*. Later, we extended that to allow providing completely custom app metadata (in which case there's no need to use the app-metadata extension).

The error message is actually quite helpful: it clearly says that nothing produces container images. In other words, you don't use any quarkus-container-image-* extension. How do you build an image to run in OpenShift? If you use source S2I, or something completely custom, you can just remove app-metadata and use @CustomAppMetadata.

[llowinge]

It looks it is needed at https://github.com/quarkus-qe/quarkus-openshift-test-suite/blob/master/app-metadata/deployment/src/main/java/io/quarkus/ts/openshift/app/metadata/AppMetadataCollector.java#L17, so it fails when no producer with ContainerImageInfoBuildItem is found. And actually https://github.com/quarkusio/quarkus/blob/master/extensions/container-image/deployment/src/main/java/io/quarkus/container/image/deployment/ContainerImageProcessor.java#L29 produces it.

[llowinge]

As a user who don't know any quarkus-container-* extensions it is not helpful at all. All it goes to the README, where we found mentioned quarkus-openshift plugin in TODO section. To me it looks like hard requirement and should be stated somewhere in the top section. As i initially thought that with EbeddedStrategy it doesn't need any other dependecies other then app-metadata + common.

[Ladicek]

It is there. There's a huge wall of text at the very top, which used to be much shorter, and then there's https://github.com/quarkus-qe/quarkus-openshift-test-suite#test-framework, which says:

This will make sure that OpenShift resources are deployed before this test class is executed, and also undeployed after this test class is executed. It is expected that a YAML file with a complete list of OpenShift resources to deploy the application is present in target/kubernetes/openshift.yml. This is what the Quarkus Kubernetes extension (or the Quarkus OpenShift extension) does, when configured correctly.

[Ladicek]

I mean -- we could copy Quarkus documentation here, but I'd really prefer not. I think it kinda makes a lot of sense to expect Quarkus OpenShift test suite users to be familiar with Quarkus and OpenShift.

[llowinge]

It is there. There's a huge wall of text at the very top, which used to be much shorter, and then there's https://github.com/quarkus-qe/quarkus-openshift-test-suite#test-framework, which says:

This will make sure that OpenShift resources are deployed before this test class is executed, and also undeployed after this test class is executed. It is expected that a YAML file with a complete list of OpenShift resources to deploy the application is present in target/kubernetes/openshift.yml. This is what the Quarkus Kubernetes extension (or the Quarkus OpenShift extension) does, when configured correctly.

I wouldn't count it as mentioned mandatory dependency. It would need proper formatting as others needed dependencies. This way no one can know that the quarkus-openshift dependency isn't eg. pulled from the common library.

[Ladicek]

If you say so. I do agree that the README isn't a good fit for people who would like to use this codebase for their own testing needs, because that has never been a goal (though I had that option in mind when originally writing the test framework code). Should that happen, some things would have to change for sure, but the expectation that people are familiar with Quarkus, OpenShift, and how Quarkus supports OpenShift would very likely stay. Also CC @rsvoboda