Closed
Bug 890349
Opened 12 years ago
Closed 11 years ago
Increase the 'make check' timeout
Categories
(Release Engineering :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: BenWa, Assigned: emorley)
References
Details
Attachments
(1 file)
1.27 KB,
patch
|
bhearsum
:
review+
|
Details | Diff | Splinter Review |
We're linking gtest-libxul on demand by design. This is great because we're not increasing the turn around time for everyone just in case they might happen to run some test.
Sadly this is tripping our timeout for 'make check'. Can we get it increased to the same timeout as our build step?
I don't have data on how frequent timeouts are during the 'make check' phase but I hope this number is low so the impact of doing this should be low as well.
My ideal solution is to have a separate build phase where we build&prepare our tests but this is a big project sadly. It would be a huge win for developers turn around times. But unless we can tackle this problem increasing the timeout is what I'm requesting here.
Reporter | ||
Comment 1•12 years ago
|
||
jmaher, do you know who can drive this? I imagine it's a simple change but I don't know who to ask.
Flags: needinfo?(jmaher)
Assignee | ||
Comment 2•12 years ago
|
||
Managed to track this down - think I have the right buildbot step/timeout value...
Attachment #785019 -
Flags: review?(bhearsum)
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → emorley
Status: NEW → ASSIGNED
Reporter | ||
Updated•12 years ago
|
Flags: needinfo?(jmaher)
Comment 3•12 years ago
|
||
Ben is out for a week so here's a driveby instead. Does the 10 minute value come from looking at jobs ? The linking of libxul for the main app takes much longer than 10 minutes on windows, where compile step has a two hour timeout.
Comment 4•12 years ago
|
||
from looking at the patch :edmorley posted, it looks as though the check command has a 5 minute limit.
Assignee | ||
Comment 5•12 years ago
|
||
(In reply to Nick Thomas [:nthomas] from comment #3)
> Ben is out for a week so here's a driveby instead. Does the 10 minute value
> come from looking at jobs ? The linking of libxul for the main app takes
> much longer than 10 minutes on windows, where compile step has a two hour
> timeout.
It's currently 5 mins without output (rather than total job length) aiui. We're intermittently hitting the current 5 min timeout in bug 886079 - the 10 mins I'm adjusting it to here is a bit of a guess.
Comment 6•11 years ago
|
||
Comment on attachment 785019 [details] [diff] [review]
Make timeout 10 mins rather than 5
Review of attachment 785019 [details] [diff] [review]:
-----------------------------------------------------------------
stamp.
do we need a similar thing in mozharness, or are we not running make check through it?
Attachment #785019 -
Flags: review?(bhearsum) → review+
Updated•11 years ago
|
Product: mozilla.org → Release Engineering
Assignee | ||
Comment 7•11 years ago
|
||
(In reply to Ben Hearsum [:bhearsum] from comment #6)
> do we need a similar thing in mozharness, or are we not running make check
> through it?
I don't believe we support it yet (both through inspecting the mozharness repo and build logs for platforms where we do use mozharness for the other steps).
Assignee | ||
Comment 8•11 years ago
|
||
Comment 9•11 years ago
|
||
In production.
Reporter | ||
Comment 10•11 years ago
|
||
Should we close this bug then?
Assignee | ||
Comment 11•11 years ago
|
||
Yup :-)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•11 years ago
|
Updated•7 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•