PFQ's running too frequently stepping on previous hardware tests |
||
Issue descriptionPer https://crbug.com/852821#c17 , we have the PFQ's running frequently enough that they sometime abort the previous run's HWTest phase. Increase from 2 to 3 hours.
,
Jul 2
Yea, looks like it's currently set to 2 hours.
,
Jul 2
Do the PFQ builders start Asynchronous test suites? If so, why? If not, shouldn't the suites be finished before the builders finish?
,
Jul 2
It looks to me like the PFQ builds are being scheduled even while the previous build is still running. Is that the bug?
,
Jul 2
The Android PFQs is scheduled with a 150 minute delay after the previous build finished. The Chrome PFQ is scheduled whenever a new build of Chrome is published by the Chrome team, but it will queue up the trigges if they happen too quickly, and so can run multiple times in a row with no delay.
,
Jul 2
Re #4 It's behaving like it used too when buildbot scheduled, but no, LUCI Scheduler isn't supposed to work that way. I believe a new config value was added so that LUCI Scheduler will never schedule more than one build at a time. Maybe we need to explicitly set that.
,
Jul 2
Oh... I suspect the buildbot scheduler may still be running against that master builder. If so, the migration to swarming + a pin bump waterfall restart should fix it.
,
Jul 6
I think that the restart went through so we're covered here now?
,
Jul 6
I confirmed that both the buildbot scheduler and the LUCI Scheduler were queuing up builds. The buildbot scheduler is now disabled. That shouldn't be problem, since that still gives the lab a long time between tests being scheduled, but it seems that it was.
,
Jul 6
|
||
►
Sign in to add a comment |
||
Comment 1 by dgarr...@chromium.org
, Jul 2