I think it could be done adding a test_type here https://cs.chromium.org/chromium/src/tools/mb/mb.py?l=1058 and make the command line call gtest-parallel.
We could also create our own script that takes care of generating the isolate file, basically a duplicate of the relevant code in mb.py

Adding a new test_type sounds like a good idea. I guess it's time for us to fork MB now, since this probably won't be interesting to have in Chromium since they have the test_launcher functionality as part of Chromium's base.

Handing this over to Edward.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/a013a02e013bef7a317cd2950539f4436c3ff2ba

commit a013a02e013bef7a317cd2950539f4436c3ff2ba
Author: kjellander <kjellander@webrtc.org>
Date: Mon Nov 14 13:54:22 2016

MB: Copy MB from Chromium repo

Essentially a copy of https://codereview.chromium.org/2299953002/
plus changes to WebRTC's license, changed OWNERS and additional
MB updates up to Chromium revision http://crrev.com/f1e2718a3ff.

The PRESUBMIT.py check was updated to use the existing
webrtc/build/mb_config.pyl to avoid breaking bots (that have
this path hardcoded).

This replaces the previously symlinked MB, which already
runs validation of the WebRTC configs as part of
webrtc/build/PRESUBMIT.py.

BUG= chromium:664425 
NOTRY=True
TESTED=Ran:
tools/mb/mb.py gen -m client.webrtc -b 'Mac64 Release' --config-file webrtc/build/mb_config.pyl --isolate-map-file=webrtc/build/gn_isolate_map.pyl --gyp-script=webrtc/build/gyp_webrtc.py //out/Release

Review-Url: https://codereview.webrtc.org/2306163002
Cr-Commit-Position: refs/heads/master@{#15068}

[modify] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/.gitignore
[modify] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/setup_links.py
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/OWNERS
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/PRESUBMIT.py
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/README.md
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/docs/README.md
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/docs/design_spec.md
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/docs/user_guide.md
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/mb
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/mb.bat
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/mb.py
[add] https://crrev.com/a013a02e013bef7a317cd2950539f4436c3ff2ba/tools/mb/mb_unittest.py

I'm curious, what is gtest-parallel and what does the interface to it look like?

Re #7: It's a Python script a developer in our team wrote: https://github.com/google/gtest-parallel

It allows for parallel execution of gtest-executables, much similar to what the test_launcher code does for Chrome (but as a script to wrap around the executable instead).

Regarding interface, it's using command line flags: https://github.com/google/gtest-parallel/blob/master/gtest-parallel#L246

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/b2fcf6d96f4efdc7a606c1cc0f999932c63226d4

commit b2fcf6d96f4efdc7a606c1cc0f999932c63226d4
Author: ehmaldonado <ehmaldonado@webrtc.org>
Date: Tue Nov 15 20:20:30 2016

MB: Run test with gtest-parallel on swarming.

TBR=pbos@webrtc.org
BUG= chromium:497757 ,  chromium:664425 
NOTRY=True

Review-Url: https://codereview.webrtc.org/2503503002
Cr-Commit-Position: refs/heads/master@{#15093}

[modify] https://crrev.com/b2fcf6d96f4efdc7a606c1cc0f999932c63226d4/third_party/gtest-parallel/gtest-parallel
[modify] https://crrev.com/b2fcf6d96f4efdc7a606c1cc0f999932c63226d4/tools/mb/mb.py
[modify] https://crrev.com/b2fcf6d96f4efdc7a606c1cc0f999932c63226d4/tools/mb/mb_unittest.py
[modify] https://crrev.com/b2fcf6d96f4efdc7a606c1cc0f999932c63226d4/webrtc/build/gn_isolate_map.pyl

[bulk-edit : please ignore if not applicable]

Could you please set the correct milestone for this issue?

@kjellander - it looks like you run one test at a time (with a new subprocess per test), is that right? And that's not too slow?

It was a long time ago I reviewed that code (pbos wrote it) but yes, that seems to be the case. At least there are no more subprocesses running than the amount of workers at any point in time. I guess spawning subprocesses might be the bottleneck for it, especially if you have many fast unit tests. We see a lot of speedup using this on our binaries at least, and it's very stable.

The following revision refers to this bug:
  https://chromium.googlesource.com/external/webrtc.git/+/aee0b5d31737f476e5c3ea2eb34e00a6f101caea

commit aee0b5d31737f476e5c3ea2eb34e00a6f101caea
Author: ehmaldonado <ehmaldonado@webrtc.org>
Date: Thu Nov 17 00:48:09 2016

Fixed a bug where only the tests in the first shard were run.

This is because:
1) The environment variables were still around when the test was executed.
2) gtest-parallel executes only one test at a time.

So when the test was invoked from a shard different than the 0th one, for example as:
./something_unittests --gtest_filter=Test.Name
It read the environment variables, and the environment variables together with the gtest_filter flag, told it that there were several shards, but only one test to be run, so if it wasn't the 0th shard, it wouldn't run the test at all.

This is fixed by erasing the environment variables once read.

Also change swarming-related flag names to fit the rest of the flags and validate their values.

NOTRY=True
BUG= chromium:497757 ,  chromium:664425 
TBR=pbos@webrtc.org, kjellander@webrtc.org

Review-Url: https://codereview.webrtc.org/2505093003
Cr-Commit-Position: refs/heads/master@{#15110}

[modify] https://crrev.com/aee0b5d31737f476e5c3ea2eb34e00a6f101caea/third_party/gtest-parallel/gtest-parallel