Yes, something like this. The details are important here though. Easier done than explained in this case -- I'll try to implement this when I get a spare minute (or at least show the way it should be done in my opinion). I filed LUCENE-9465 to track this effort.
D. On Sun, Aug 16, 2020 at 6:14 AM Mike Drob <[email protected]> wrote: > > I was trying to make this work but ran into a few walls of my own gradle > knowledge. I was doing this with a trivial project, not the whole of lucene, > so I'm sure there will be additional integration pains. > > Regardless, sharing my progress thus far: > > configure(rootProject) { > Integer.getInteger("beast.iters", 3).times { > tasks.create(name: "beastRun$it", type:Test) > } > task beast() { > dependsOn rootProject.collect { > tasks.matching { task -> task.name.startsWith("beastRun") } > } > } > } > > I was able to get this to execute a test multiple times, and save the output > to separate test directories (build/test-results/beastRunN). It respects > -Dbeast.iters so you can control the number of executions > > Things still to address > - this pollutes the task graph and especially if you are running 'gradle > tasks' it gets messy. Probably need to use register instead of create, but I > couldn't make that work with the API. > - I couldn't get them to run in parallel, they were running serially for me > - I didn't get this to accept the standard test selection flags. > > Maybe I'll have more time during the week, or maybe somebody else will run > with this. > > Mike > > > > > On Sat, Aug 15, 2020 at 4:11 PM Dawid Weiss <[email protected]> wrote: >> >> I suspect the "beasting" script would be best simulated by creating X >> test tasks (with different names but identical configuration). Then >> gradle can take care of parallelism serving those tasks to its worker >> VMs. This would accomplish many things at once: everything would run >> from within a single gradle parent process (daemon or not), tests >> would be run in parallel, the first failure could abort execution of >> subsequent tasks, etc. >> >> There are some open questions - whether beasting should run with the >> same temporary folders (probably not) whether gradle will be smart >> enough to collect report for multiple test with the same name >> (probably not)... you know - the devil is in the details. But I think >> it'd be an ideal way to do it: no need for external trickery, scripts, >> multi-platform compatibility, etc. >> >> Anyone up to the challenge? :) >> >> Dawid >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
