And to answer the original question, I've used it from time to time. Also I think "gradle magic" might be best if it can ensure that gradle doesn't go through the process of checking for the need to recompile etc on every cycle.
I'm against containers being required for something like this because my desktop BIOS fails to support virtualization correctly so some things related to containerization don't want to run it or run in limited ways. If it's really the best option for everyone else, fine, but I'm not enthusiastic about it. @Robert Muir mark's script does use parallel. Also I suspect I can guess, but could we define "pure unit test" to ensure I haven't got a different concept of that than what you mean? On Sat, Aug 15, 2020 at 11:25 AM Gus Heck <[email protected]> wrote: > If you're beasting a single test that won't take advantage of multiple > processors... > > On Sat, Aug 15, 2020 at 10:31 AM Robert Muir <[email protected]> wrote: > >> Is a beasting script needed with gradle? Can't you do it efficiently with >> a simple shell script loop? If you have the gradle daemon running, overhead >> will be minimal (unlike ant) ? That's kinda the point of the daemon right? >> >> Here's the kind of loop i typically use for stuff like this, right from >> bash console: log the output for each run to individual files and just >> print the exit status so i can see progress as it goes. >> >> for i in {1..100}; do >> gradlew test ... > /tmp/$i.log 2>&1 >> echo -n $? >> done >> >> On Sat, Aug 15, 2020 at 9:37 AM Erick Erickson <[email protected]> >> wrote: >> >>> I often use “The best Lucene / Solr beasting script in the world. TM.” ( >>> https://gist.github.com/markrmiller/dbdb792216dc98b018ad). >>> >>> The it struck me out of the blue (well actually since I’ve been beasting >>> for SOLR-14750 a lot), “Gosh, when we remove Ant from trunk I won’t be able >>> to use the beast script”. >>> >>> So I wanted to ask how many people use it and what people’s thoughts are >>> about what to do after we remove Ant from trunk. Off the top of my head, >>> options are: >>> >>> 1> find some Gradle magic that will do this. >>> >>> 2> modify the script to work with Gradle instead (if possible). >>> >>> 3> just do without it or an equivalent (booooo!) >>> >>> 4> In the brave new world of containers, is there a simple way to fire >>> up N simultaneous but independent instances of the _same_ test and keep >>> them running until the limit is reached? We’d need to be able to change >>> code and fire up the script without too much work, and having the results >>> all written to beast/res/1/(1, 2, 3, 4, 5)/stdout is necessary, as well as >>> being able to have an “all succeeded” message at the end. >>> >>> 5> ??? >>> >>> I’ll ping mark and see if he’s got some magic that he’s been using with >>> the reference impl. >>> >>> I don’t think tests.iters is a good replacement for two reasons: >>> >>> a> part of the usefulness of the beasting script is that it fires up a >>> bunch of parallel tests, stressing the system. >>> >>> b> last I knew, it needs to be run for pure unit tests, and Solr has >>> lots of tests that are not. >>> This is from Robert Muir from some time ago specific to Ant, would >>> it still be valid? >>> >>> ————--- >>> Long answer: It has been discussed on the list several times. >>> tests.iters does not do what a lot of people seem to think. >>> From what i remember: it creates your test *class* a single time and >>> runs stuff repeatedly... I think only (new *instance*, setup, >>> teardown, etc). I don't even think it runs e.g. beforeclass/afterclass >>> stuff between iterations either, but that still wouldnt make it >>> completely safe anyway unless the whole class was recreated (a test >>> could leave a static variable in a different state or something). >>> >>> So if your test isn't a pure unit test, its probably not ready for >>> tests.iters. Just use ant beast, it works :) >>> ----------- >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > -- > http://www.needhamsoftware.com (work) > http://www.the111shift.com (play) > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
