New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 850738 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Feature



Sign in to add a comment

Ensure that HWTest is enabled before hardware is delivered to the lab

Reported by jrbarnette@chromium.org, Jun 7 2018

Issue description

Recently, the first model (vayne) for a new board (nami) was delivered
to the lab.  However, the release builders for the board had no
HWTest stages configured, so no tests began running.  The devices
sat idle and untested, despite the availability of images.

We need to adjust our process for creating builders so that this can't
happen.

Prior to the advent of unibuilds, the process worked by requiring that
every release builder would configure HWTest at creation time.  A unit
test enforced the rule.  When BVT was scheduled from a release builder, if
no hardware existed, the result was ignored.  Thus, the moment hardware
was added to the lab, tests would begin running automatically.

We need to fix release builder creation to enforce that testing will begin
as soon as hardware is available.  The simplest way would be to add a
unit test that enforces that for any unibuild release builder, at least
one model is configured to run HWTest.  Assuming the first model configured
is also the first model delivered to the lab, that should be good enough.

 
Cc: jclinton@chromium.org yueherngl@chromium.org
I think this was an intentional setting by whomever created the new models, it looks like the default when creating a new model in GE does have this enabled, so I am guessing someone turned them all off.

I went ahead and enabled testing for all Nami models except for Nami itself in GE, so the config updater should push this out in another hour or so.
FWIW, all future models should have lab deployments and testing by policy, only some of the legacy unified builds (e.g. coral) will have models that are expected to not be running lab tests.

As such we should probably send out a PSA to those whom create models (partner engineering?) that we should have all tests enabled. 
Labels: OS-Chrome
Cc: stephenlin@chromium.org
> As such we should probably send out a PSA to those whom create
> models (partner engineering?) that we should have all tests enabled. 

That's a good start.  I'd also recommend that the GE UI disallow completely
turning off testing.  Too many people just won't get the memo.

Labels: -Type-Bug -Pri-2 Pri-3 Type-Feature
Sounds like a good idea. Will do it in Q4 or Q1.
Cc: leecy@chromium.org
Cc: englab-sys-cros@google.com
Labels: -Type-Feature Type-Bug-Regression
> Sounds like a good idea. Will do it in Q4 or Q1.

I think it would be good to do something before that time.
New EVT hardware is constantly arriving in the lab, and with
the current process, that hardware can sit unused indefinitely,
because the system no longer automatically starts BVT testing.

Just to drive home the point:  This problem has just this week
affected the Grunt EVT deployment.

Also - changing this from "Feature" to "Regression".  The standard
behavior for several years has been that BVT testing begins automatically
when there's hardware in the BVT pool.  That behavior is now broken.

Labels: -Type-Bug-Regression Type-Feature
Status: Available (was: Untriaged)
Please don't change our triaged bug values. I considered the priority against all of the other things that we have to do and that's where it landed. I don't agree with your assessment because this is only very late error catch from someone not using the GE UI correctly. That entire UI is going away as soon as your teams' Test Console launches which should be soon.

Cc: nsanders@chromium.org

Sign in to add a comment