ctubbsii commented on PR #5555: URL: https://github.com/apache/accumulo/pull/5555#issuecomment-2892174842
> @kevinrr888 - do you want to try and resolve @ctubbsii's [comment](https://github.com/apache/accumulo/pull/5536#pullrequestreview-2844416668) as part of this PR? If not, I can take a look at it in a different one. I took a look at this today, because it got in the way of running an explicit test I tried to run with `-Dit.test=`, and spent some time trying to think about how it could be fixed. Right now, it explicitly overrides the `test` variable, which is a bit overloaded between the surefire and failsafe plugin. In addition, it also abides by the groups, excludedGroups, forkCount, and other properties that are intended for the other execution. It also conflicts with the -Psunny profile, which activates a group. It gets really complicated to try to write a profile that excludes this second execution whenever any of these options are present. It might be possible if people used the property names only, and then we can have a big list of properties like: ```xml <profile> <id>shared-mini-suite-its</id> <activation> <property> <name>!test</name> </property> <property> <name>!it.test</name> </property> <property> <name>!groups</name> </property> <property> <name>!excludedGroups</name> </property> <!-- etc.... --> </activation> ``` However, this won't work for the sunny profile, because the profile activation checks run before the sunny profile can set the SunnyDay groups property. A better option would be to set the second execution in a separate Maven module by moving all these tests to a different module. That's a bit frustrating, and comes with its own downsides, but it would allow us to honor user-specified command-line options by making the plugin behavior driven by properties, rather than hard-coded values that affect the plugin. An alternative would be to create a suite of new properties that are specific to this execution, and hard-code them into the execution's config, as in: ```xml <execution> <configuration> <test>${sharedMiniTest}</test> <groups>${sharedMiniGroups}</groups> <excludedGroups>${sharedMiniExcludedGroups}</excludedGroups> <!-- etc... --> ``` Another option is to have only the suite entry point test be available for selection, and don't treat it like a separate group. That would require renaming all the ITs in that suite, so they don't get picked up by the `*IT` naming pattern, and then they really only can be run all or nothing (by executing the suite test class). None of these seem like great options to me, but something needs to be done to make it possible to run individual tests again without picking up all the suite tests, because they are hard-coded to run every time, regardless of user input. Because of how disruptive it is to not be able to run individual tests, I'm considering reverting the commit that added the suite, unless we can get some workable solution soon. The time savings in Jenkins is not substantial enough to warrant that loss of functionality, in my opinion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@accumulo.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
