Tracking bug for the post-commit hardware test effort.
VM-tests are up and running on the CQ:
https://luci-milo.appspot.com/p/chromium/builders/luci.chromium.try/chromeos-amd64-generic-rel?limit=200
Time to get hardware coverage as well. We've already got the hardware in swarming:
https://chromium-swarm-dev.appspot.com/botlist?c=id&c=os&c=task&c=status&f=os%3AChromeOS&l=100&q=os%3A&s=id%3Aasc
Which is (theoretically) running telemetry unittests:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/ChromeOS%20Swarm
All of which is in varying states of disrepair. Off the top of my head, TODOs are:
- Resuscitate the hardware.
- Keep the hardware alive.
- Set up monitoring of their health. (a la android)
- Get the chromebooks on our weekly repair cycles so they can get automatically revived. (a la android)
- (Also figure out how to stop the OOBE tutorial video which seems to shut down the ethernet adapter.... or something.)
- Develop auto-flashing story.
- Package cros' "cros flash" utility into an isolate.
- Regularly fetch the latest stable images from chromeos-image-archive GS bucket.
- Schedule a nightly/weekly cron to flash those images onto the chromebooks using the isolate.
- Flesh out test runner scripts in //build/chromeos/ to support running hardware (along with VMs).
- Set up simplechrome waterfall builder which builds the tests. (Like the VM builder, but targeting the HW's board.)
- Run the tests.
- ???
- Profit
If all goes well, that should put us in a good position to start looking into running perf benchmarks on the hardware as well. But that's for another bug.
Comment 1 by bugdroid1@chromium.org
, Jul 25