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]
>
>
