90 seconds for a simple test sounds like a lot of time and a huge bump from the current situation (45). The risk is people will start writing much bigger tests instead of splitting them into smaller an more manageable tests. Plus when a test depends on a long timeout in the product, developers are used to figure out ways to reduce those (through hidden prefs or such) so that test can finish sooner and not timeout. Based on that, bumping the timeout may have 2 downsides, long term: - slower tests for everyone - sooner or later 90 seconds won't be enough again. Are we going to bump to 180 then?
I think that's the main reason the default timeout was set to a low value, while still allowing the multipliers as a special case for tests that really require bigger times, cause there's no other way out. Is docker doubling the time for every test? From the bug looks like it may add 20-30% of overhead, so why are we not bumping the timeout of 30% (let's say 60s) and investigating the original cause (the bug that takes 80s to run) to figure if something can be done to make it finish sooner? -m On Mon, Feb 8, 2016 at 11:51 PM, Armen Zambrano G. <arme...@mozilla.com> wrote: > Hello, > In order to help us have less timeouts when running mochitests under > docker, we've decided to double mochitests' gTimeoutSeconds and reduce > large multipliers in half. > > Here's the patch if you're curious: > > https://bugzilla.mozilla.org/page.cgi?id=splinter.html&bug=1246152&attachment=8717111 > > If you have any comments or concerns please raise them in the bug. > > regards, > Armen > > -- > Zambrano Gasparnian, Armen > Automation & Tools Engineer > http://armenzg.blogspot.ca > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
