Open
Bug 1294706
Opened 8 years ago
Updated 2 years ago
"Mochitest other" chunk on win7 debug slow and often last to complete
Categories
(Testing :: Mochitest, defect)
Testing
Mochitest
Tracking
(Not tracked)
NEW
People
(Reporter: wlach, Unassigned)
References
(Blocks 1 open bug)
Details
Similar to mochitest dt9 (bug 1294489), based on Infraherder it looks like Mochitest other on win7 debug often takes significantly longer than its mochitest breathen, frequently becoming the long poll in a sequence of jobs: e.g. in this try push https://treeherder.mozilla.org/#/jobs?repo=try&revision=8f6eac7f74fb7775617e3acd089aec43de3e24ff&selectedJob=25873461 M-1: 37 minute(s) M-2: 40 M-3: 52 M-4: 37 bc-1: 28 bc-2: 31 bc3: 34 bc4: 35 bc5: 30 bc6: 29 bc7: 24 cl: 29 gl: 50 ---> o: 82 <--- Renormalizing the chunk size might be in order? This chunk also seems to be a problem on linux: https://treeherder.mozilla.org/index.html#/jobs?repo=try&revision=a82435791b8198de368cd322da798e138408891e&selectedJob=25876934
Comment 1•8 years ago
|
||
mochitest-other runs several Mochitest variants together. Historically we did that to amortize the setup time over a few short jobs, but maybe it's time to split them out into their own jobs? It looks like all that's left in there is mochitest-chrome and mochitest-a11y, so splitting that into two jobs does not seem unreasonable.
Reporter | ||
Comment 2•8 years ago
|
||
Another problem with these long running jobs is that our "auto retrigger failing jobs on try" behaviour will waste 2x the # of cycles. You can see that in the example I linked to above.
Comment 3•8 years ago
|
||
prior art in bug 1211889, we didn't have enough builders in buildbot to do this in the past. It might be worth trying again, I think linux64 was the main issue.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•