STONEBLD-1514 CLI and contaminated test jars #872
Conversation
...equest-processor/src/main/java/com/redhat/hacbs/container/analyser/deploy/DeployCommand.java
Show resolved
Hide resolved
...equest-processor/src/main/java/com/redhat/hacbs/container/analyser/deploy/DeployCommand.java
Outdated
Show resolved
Hide resolved
| import io.quarkus.test.junit.QuarkusTest; | ||
|
|
||
| @QuarkusTest | ||
| @QuarkusTestResource(value = LogCollectingTestResource.class, restrictToAnnotatedClass = true, initArgs = @ResourceArg(name = LogCollectingTestResource.LEVEL, value = "FINE")) |
There was a problem hiding this comment.
I looked at https://quarkusio.zulipchat.com/#narrow/stream/187030-users/topic/Test.20Logging.3F which led to a few options but using quarkusio/quarkus@7c81682 seemed simplest
There was a problem hiding this comment.
To be honest I don't really like tests like this, they are really fragile and tied to the implementation.
I would create two repos at https://github.com/orgs/jvm-build-service-test-data/repositories , one called 'unbuildable' or something like that, and one where the test jar is contaminated by unbuildable. I think you should have access, both to be able to create the repos and release to central.
Then add the gav of the contaiminated one to the minikube test matrix.
Over time I want to build up https://github.com/orgs/jvm-build-service-test-data to contain all sorts of different problems we have solved, but that only have one or two classes so they build super quick.
java-components/cli/src/main/java/io/github/redhatappstudio/jvmbuild/cli/DiagnosticCommand.java
Show resolved
Hide resolved
...equest-processor/src/main/java/com/redhat/hacbs/container/analyser/deploy/DeployCommand.java
Outdated
Show resolved
Hide resolved
java-components/cli/src/main/java/io/github/redhatappstudio/jvmbuild/cli/DiagnosticCommand.java
Show resolved
Hide resolved
| import io.quarkus.test.junit.QuarkusTest; | ||
|
|
||
| @QuarkusTest | ||
| @QuarkusTestResource(value = LogCollectingTestResource.class, restrictToAnnotatedClass = true, initArgs = @ResourceArg(name = LogCollectingTestResource.LEVEL, value = "FINE")) |
There was a problem hiding this comment.
To be honest I don't really like tests like this, they are really fragile and tied to the implementation.
I would create two repos at https://github.com/orgs/jvm-build-service-test-data/repositories , one called 'unbuildable' or something like that, and one where the test jar is contaminated by unbuildable. I think you should have access, both to be able to create the repos and release to central.
Then add the gav of the contaiminated one to the minikube test matrix.
Over time I want to build up https://github.com/orgs/jvm-build-service-test-data to contain all sorts of different problems we have solved, but that only have one or two classes so they build super quick.
No description provided.