Mind listing some of the potential tests here too? Thanks!

Existing autotest: 
login_GaiaLogin
platform_DriveFs
cheets_PlayStoreTest
cheets_PlayStoreTest_P
cheets_PerfBootServer
cheets_EnterpriseForceInstall
cheets_EnterpriseLogin
cheets_AuthPerf
cheets_DataMigrationPlayStore_P

And the Assistant tests that I have not built yet :)

I suspect that this won't require much code. I think that a good starting point is the NavigateGaiaLogin function in telemetry/telemetry/internal/backends/chrome/oobe.py in Catapult.

I might be able to look at this a bit in January, but someone else should feel free to steal it from me if they need it quickly. Attaching a tiny initial part of the work that adds an enum value and renames an existing value.

Deleted: gaia.diff 1.6 KB

gaia.diff 1.6 KB Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/5d2a4e3d35678aa449b3756bc7969a7dc7e95636

commit 5d2a4e3d35678aa449b3756bc7969a7dc7e95636
Author: Daniel Erat <derat@chromium.org>
Date: Fri Jan 11 21:32:30 2019

tast-tests: Make chrome package support GAIA login.

Add a new GAIALogin option that can be passed to chrome.New
to indicate that real login should be performed using the
GAIA backend.

BUG=chromium:903521
TEST=manually verified using a new test; also added unit
     tests for email-normalization code

Change-Id: Ib51215fbaee1b0c2d868b2b735c06ecc86ef2cbb
Reviewed-on: https://chromium-review.googlesource.com/1405215
Commit-Ready: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>

[add] https://crrev.com/5d2a4e3d35678aa449b3756bc7969a7dc7e95636/src/chromiumos/tast/local/session/normalize_test.go
[add] https://crrev.com/5d2a4e3d35678aa449b3756bc7969a7dc7e95636/src/chromiumos/tast/local/session/normalize.go
[modify] https://crrev.com/5d2a4e3d35678aa449b3756bc7969a7dc7e95636/src/chromiumos/tast/local/chrome/chrome.go

We still need to figure out a good way to store GAIA credentials. Copying nya@'s comment: "Private tests can hide credentials, but I'm not sure if it's good to make a test private just because it uses GAIA logins. Ideally we may want a way to provide credentials to public tests, possibly via command line flags."

One of the main considerations here is whether credentials need to be unique across tests. If it's okay to use the same account across all tests that perform GAIA login, then yes, I could imagine a command-line flag (or environment variable?) working here: in the lab, we could probably store the password somewhere that isn't publically accessible, and developers could run the same tests manually by passing their own test account credentials instead.

I think this problem is similar to "secrets" in deploying web applications (for example, web apps needing credentials to connect to SQL databases).

One possible way would be to support passing arbitrary "secret" key/value pairs on running tests. Like:

 tast run --secret google.user=example@gmail.com --secret google.pass=foobar DUT chrome.GAIALogin
 or
 tast run --secretfile secrets.yaml DUT chrome.GAIALogin

Then Chrome tests would query it by some API:

 func (s *testing.State) Secret(key string) string { ... }

It would be important to name it "secret" (or something similar) so that people don't use it for arbitrary purposes, such as specifying the number of test iterations.

Hmm, seeing the proposed -secretfile flag makes me wonder if this is more like a special case of an external data file. I guess that one of the main differences is that external data files currently have hardcoded public URLs, while in this case we'd need user-controlled non-public (file://?) URLs. It would be nice if supporting this didn't require a separate "copy a file to the DUT so that tests can access it" implementation, though.

Do you have any thoughts about how we'd store credentials when tests are being executed in the lab? Would we want to point at file stored in an internal GCS bucket?