[DROOLS-7499] create drools-reliability-tests #5390
Conversation
| @@ -44,9 +44,16 @@ static ReliableGlobalResolverFactory get() { | |||
|
|
|||
| static class ReliableGlobalResolverFactoryImpl implements ReliableGlobalResolverFactory { | |||
|
|
|||
| static int servicePriorityValue = 0; // package access for test purposes | |||
There was a problem hiding this comment.
drools-reliability-tests depends on both drools-reliability-infinispan and drools-reliability-h2mvstore, so KieService loading will conflict. So I made servicePriority changeable to avoid the conflict and to choose an expected service based on surefire execution (using system property. See also TestConfigurationUtils). This is a little messy. @mariofusco If you have an idea to implement it better (enhance KieService?), feel free to let me know.
There was a problem hiding this comment.
@tkobayas I agree that the current KieService implementation is a bit cumbersome and unclear for this specific purpose. We could think to something more explicit, like tagging a service with a String or enum and asking for a service with that specific tag when loading it. As I said this will make things a bit more explicit but anyway it will require to have the value for the tag in a static field and change it in tests, in a similar way as you did for priority. The other small advantage is that this tag could be used by more than one service, so in your tests you could do something like
reliabilityPersistanceLayer = "H2";
and read the value of that same tag for all reliability related services, instead of changing priority for 3 different services like you're obliged to do now. Note that this tagging mechanism couldn't replace the current priority based one, but only be complementary to it.
That said I'm happy with this pull request and think that it could be merged as it is. The improvement for tagged services could be implemented with a subsequent commit. If you agree with this suggestion feel free to open another jira for this and work on it when you have time (or assign the task to me if you prefer).
There was a problem hiding this comment.
Thank you, @mariofusco , it makes sense. I filed https://issues.redhat.com/browse/DROOLS-7508 to work on next.
| <!-- | ||
| NOTE: If you want to run single test, you need to write like this: | ||
| mvn surefire:test@default-test -Dtest=ReliabilityCepTest | ||
| Otherwise, it will run all executions (smoke-tests-remote etc.) | ||
| --> |
There was a problem hiding this comment.
As noted, If you want to run single test, you need to write like this:
mvn surefire:test@default-test -Dtest=ReliabilityCepTest
Otherwise, it will run all executions (smoke-tests-remote etc.)
|
Kudos, SonarCloud Quality Gate passed! |
Moved all tests to this newly created
drools-reliability-teststo be shared by different configurations.JIRA:
https://issues.redhat.com/browse/DROOLS-7499
How to replicate CI configuration locally?
Build Chain tool does "simple" maven build(s), the builds are just Maven commands, but because the repositories relates and depends on each other and any change in API or class method could affect several of those repositories there is a need to use build-chain tool to handle cross repository builds and be sure that we always use latest version of the code for each repository.
build-chain tool is a build tool which can be used on command line locally or in Github Actions workflow(s), in case you need to change multiple repositories and send multiple dependent pull requests related with a change you can easily reproduce the same build by executing it on Github hosted environment or locally in your development environment. See local execution details to get more information about it.
How to retest this PR or trigger a specific build:
for pull request checks
Please add comment: Jenkins retest this
for a specific pull request check
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] tests
for a full downstream build
run_fdba compile downstream build please add comment: Jenkins run cdb
a full production downstream build please add comment: Jenkins execute product fdb
an upstream build please add comment: Jenkins run upstream
for quarkus branch checks
Run checks against Quarkus current used branch
Please add comment: Jenkins run quarkus-branch
for a quarkus branch specific check
Run checks against Quarkus current used branch
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] quarkus-branch
for quarkus main checks
Run checks against Quarkus main branch
Please add comment: Jenkins run quarkus-main
for a specific quarkus main check
Run checks against Quarkus main branch
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] quarkus-main
for quarkus lts checks
Run checks against Quarkus lts branch
Please add comment: Jenkins run quarkus-lts
for a specific quarkus lts check
Run checks against Quarkus lts branch
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] quarkus-lts
for native checks
Run native checks
Please add comment: Jenkins run native
for a specific native check
Run native checks
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] native
for native lts checks
Run native checks against quarkus lts branch
Please add comment: Jenkins run native-lts
for a specific native lts check
Run native checks against quarkus lts branch
Please add comment: Jenkins (re)run [drools|kogito-runtimes|kogito-apps|kogito-examples] native-lts
How to backport a pull request to a different branch?
In order to automatically create a backporting pull request please add one or more labels having the following format
backport-<branch-name>, where<branch-name>is the name of the branch where the pull request must be backported to (e.g.,backport-7.67.xto backport the original PR to the7.67.xbranch).Once the original pull request is successfully merged, the automated action will create one backporting pull request per each label (with the previous format) that has been added.
If something goes wrong, the author will be notified and at this point a manual backporting is needed.