-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Java Operator JUnit Extension is unusable from Quarkus #328
Comments
Do you need both Local and Remote support ? Remote would require the image to be built but I'm not sure quarkus do it before running the tests. Like the OLM testing, it could not be a mvn one liner as with josdk. For local, I think that what you are asking can interest Quarkus k8s development more broadly as part of Dev Service experience. Maybe with quarkus-kind or quarkus-minikube extension, a cluster can be created if not detected during dev and tests. Nonetheless, what about a custom QuarkusTestResourceLifecycleManager that can wrap an AbstractOperatorExtension to just prepare the cluster and let quarkus run the app normally. Meaning, the JOSDK JUnit extension is not responsible of creating and running the operator instance because it should not in the first place. |
I forgot to give more context to this issue. And that's the reason why I contributed this functionality to the JOSDK. |
That's the approach we decided to take: we will write a Quarkus test resource that deals with setting up the cluster, though I'm not sure how much code we'll be able to reuse from the JOSDK JUnit extension… |
Trying to use the Java Operator JUnit Extension from a project using the Quarkus Operator SDK results in multiple errors and, currently, is impossible to run the tests.
Here you can find a minimal reproducer:
https://github.com/andreaTP/operator-junit-repro
Additional considerations:
quarkus.operator-sdk.start-operator=false
seems that there are 2 operators started:and there are consistently duplicated logs.
the JUnit extension relies on the fact that CRDs are generated in a specific location maybe we should consider adding the
crd-generator-apt
as a transitive dependencies (or make the location more easily configurable)the current blocking issue seems to be the fact the framework is unable to load the configuration for the reconciler:
cc. @DGuhr @metacosm @csviri
The text was updated successfully, but these errors were encountered: