sure but you can probably install a tool like 'parallel' if you want that. 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) >
