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

Reply via email to