New issue
Advanced search Search tips

Issue 859683 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 6
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

PFQ's running too frequently stepping on previous hardware tests

Project Member Reported by jclinton@chromium.org, Jul 2

Issue description

Per  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.
 
Do you want to slow down how often they are built?
Yea, looks like it's currently set to 2 hours.
Do the PFQ builders start Asynchronous test suites? 

If so, why?
If not, shouldn't the suites be finished before the builders finish?
It looks to me like the PFQ builds are being scheduled even while the previous build is still running. Is that the bug?
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.
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.


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.
I think that the restart went through so we're covered here now?
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.
Status: Fixed (was: Started)

Sign in to add a comment