Prevent parallelization of ash browsertests on the same machine.

Prevent parallelization of ash browsertests on the same machine.

BUG=286205

[gab, 2014-01-10 22:26:29]

As you suggested on the bug.

I'm not familiar at all with these configs, do I CQ or dcommit changes here?

Thanks!
Gab

[gab, 2014-01-13 17:02:05]

On 2014/01/10 22:26:29, gab wrote:
> As you suggested on the bug.
> 
> I'm not familiar at all with these configs, do I CQ or dcommit changes here?
> 
> Thanks!
> Gab

@phajdan.jr: friendly ping

PS: Will a master restart be required for those to kick in?

Thanks!

[Paweł Hajdan Jr., 2014-01-13 18:41:34]

Hey Gabriel, yes this would require a master restart. In this case I also
believe it's not the right way to fix it. "not lgtm"

Good news is that the right way would not need a master restart. Please see
chrome/test/base/browser_tests_main.cc - if that's the main for your test
binary, just force the number of jobs to one on --ash-browsertests (make sure to
print something about that and flush stdout). Send the review my way.

Let me know if I can help more. The idea is that the information it needs to run
serially should be within the test binary itself, rather than duplicated in
every caller.

[gab, 2014-01-15 20:04:04]

On 2014/01/13 18:41:34, Paweł Hajdan Jr. wrote:
> Hey Gabriel, yes this would require a master restart. In this case I also
> believe it's not the right way to fix it. "not lgtm"
> 
> Good news is that the right way would not need a master restart. Please see
> chrome/test/base/browser_tests_main.cc - if that's the main for your test
> binary, just force the number of jobs to one on --ash-browsertests (make sure
to
> print something about that and flush stdout). Send the review my way.
> 
> Let me know if I can help more. The idea is that the information it needs to
run
> serially should be within the test binary itself, rather than duplicated in
> every caller.

sg, sent you https://codereview.chromium.org/132313006/ for this. Closing this
one now.

Cheers,
Gab