commit	9b13af1f6a131bdbce96289a87fae134c39d3223	[log] [tgz]
author	Sean Abraham <seanabraham@chromium.org>	Wed Oct 09 21:18:35 2019 +0000
committer	Sean Abraham <seanabraham@chromium.org>	Wed Oct 09 21:23:05 2019 +0000
tree	6553decd0cc8196e501a7accece2dda899704541
parent	6485a03b1a6f2433b24b7afad69c14e1f9b1b9f3 [diff]

Revert "Add applicable_models to TestConfig."

This reverts commit 5b5ddff0e8c3bab5634e4d4753df6ae8577934de.

Reason for revert: breaks chromite unit tests, as in https://ci.chromium.org/p/chromeos/builders/cq/chromite-cq/b8900050863131122272 


======================================================================
ERROR: [chromite.lib.paygen.paygen_build_lib_unittest] HWTest.testTestPlan
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/host/source/chromite/lib/timeout_util.py", line 191, in TimeoutWrapper
    return func(*args, **kwargs)
  File "/mnt/host/source/chromite/lib/paygen/paygen_build_lib_unittest.py", line 1327, in testTestPlan
    build='dummy-build')
  File "/mnt/host/source/chromite/lib/paygen/paygen_build_lib.py", line 1248, in _TestPlan
    shown_test_name = '%s_%s' % (test_name, payload_test.unique_name_suffix())
  File "/mnt/host/source/src/third_party/autotest/files/site_utils/autoupdate/lib/test_params.py", line 132, in unique_name_suffix
    self.source_release, self.payload_type.lower())
AttributeError: 'NoneType' object has no attribute 'lower'


Original change's description:
> Add applicable_models to TestConfig.
> 
> The applicable_models are the list of models that an FSI config should
> run against. These come from the paygen.json provided by GE and will be
> passed in here by chromite's paygen_build_lib. Currently we run all FSI
> configs on all unibuild models. With the applicable_models list here it
> will be easy to filter configs by model.
> 
> Also removes a hack for figuring out suffix of test name in a previous
> CL while I waited for a chromite CL to land.
> 
> BUG=chromium:909972
> TEST=tryjob
> 
> Change-Id: I19b0845467aad0a09832f073fb0df53b9e37ee78
> Reviewed-on: https://chromium-review.googlesource.com/1834105
> Tested-by: David Haddock <dhaddock@chromium.org>
> Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org>
> Reviewed-by: Amin Hassani <ahassani@chromium.org>

Bug: chromium:909972
Change-Id: Iac227c7414843f6c756ce9b4386e47dfbacff59c
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/autotest/+/1850712
Reviewed-by: Sean Abraham <seanabraham@chromium.org>
Reviewed-by: David Haddock <dhaddock@chromium.org>
Commit-Queue: Sean Abraham <seanabraham@chromium.org>
Tested-by: Sean Abraham <seanabraham@chromium.org>

site_utils/autoupdate/lib/test_params.py[diff]

1 file changed

tree: 6553decd0cc8196e501a7accece2dda899704541

README.md

Autotest: Automated integration testing for Android and Chrome OS Devices

Autotest is a framework for fully automated testing. It was originally designed to test the Linux kernel, and expanded by the Chrome OS team to validate complete system images of Chrome OS and Android.

Autotest is composed of a number of modules that will help you to do stand alone tests or setup a fully automated test grid, depending on what you are up to. A non extensive list of functionality is:

A body of code to run tests on the device under test. In this setup, test logic executes on the machine being tested, and results are written to files for later collection from a development machine or lab infrastructure.
A body of code to run tests against a remote device under test. In this setup, test logic executes on a development machine or piece of lab infrastructure, and the device under test is controlled remotely via SSH/adb/some combination of the above.
Developer tools to execute one or more tests. test_that for Chrome OS and test_droid for Android allow developers to run tests against a device connected to their development machine on their desk. These tools are written so that the same test logic that runs in the lab will run at their desk, reducing the number of configurations under which tests are run.
Lab infrastructure to automate the running of tests. This infrastructure is capable of managing and running tests against thousands of devices in various lab environments. This includes code for both synchronous and asynchronous scheduling of tests. Tests are run against this hardware daily to validate every build of Chrome OS.
Infrastructure to set up miniature replicas of a full lab. A full lab does entail a certain amount of administrative work which isn't appropriate for a work group interested in automated tests against a small set of devices. Since this scale is common during device bringup, a special setup, called Moblab, allows a natural progressing from desk -> mini lab -> full lab.