Hi again,
I looked at the currently committed parallel test execution tooling and
summarize existing solutions for machines with many cores below.
I would still be very much interested to know how the existing defaults perform
for typical dev setups. Every additional data point would be very
Hi Ben,
I use the parallel exclusively on a 8 hyperthreads Mac OS machine and a 16 core
Fedora box. For me only known flaky tests fail.
Currently the target parallelity is calculated rather naively and can e.g. grow
without bound which will become an issue on machines with many cores. I would
Is anyone using the parallel test runner? I did another test of it today
and it triggered 278 failing tests. I noticed a lot of timeouts so I tried
bumping the default wait time from 15 seconds to 120 seconds. That brought
it down to 43 failures.
Taking a look at the remaining failures, it seems
Thanks for pushing this through Benjamin!
I understand if you're unable to attend the community sync on the 20th,
but would you be able to present this as a demo somehow? maybe via a
screencast?
MPark
On Thu, Oct 13, 2016 at 6:33 PM, Benjamin Mahler wrote:
> Great to see
Great to see this Benjamin!
Looking forward to seeing the parallel test runner turn green, I'll help
file tickets under the epic (I see there are a lot of test failures for me).
Once we clear the issues and turn it green, shall we make this the default?
I would be in favor of that.
Ben
On Thu,
This is great, Benjamin!
I've used it the whole day today and it is awesome. (It will become
insanely great once MESOS-6387 is resolved.)
Thanks for everyone who made this happen, also on behalf of my employer : )
Alex.
On Thu, Oct 13, 2016 at 11:28 PM, Benjamin Bannier <
Hi,
Since most tests in the Mesos, libprocess, and stout test suites can
be executed in parallel (the exception being some `ROOT` tests with
global side effects in Mesos), we recently added a parallel test
runner `support/mesos-gtest-runner.py`. This should allow to
potentially significantly