commit | 7ed9632bfe31c5ab7f403f95194c1d8047999374 | [log] [tgz] |
---|---|---|
author | Yu-Ping Wu <yupingso@chromium.org> | Fri Jul 31 08:25:39 2020 |
committer | Commit Bot <commit-bot@chromium.org> | Thu Sep 17 07:06:07 2020 |
tree | 17d667a29dfb21c4b9e6194304ce05e7603c1596 | |
parent | 798cfb8fb0394a859621405775d87b94d259151f [diff] |
fw-testing-config: Add asurada.json BUG=b:161206507 TEST=FAFT suite:bvt-faft passed Change-Id: I51551f55738114d357a9268bd185d5edc37dde3b Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/fw-testing-configs/+/2397756 Tested-by: Yu-Ping Wu <yupingso@chromium.org> Commit-Queue: Yu-Ping Wu <yupingso@chromium.org> Auto-Submit: Yu-Ping Wu <yupingso@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
go/cros-fw-testing-configs-guide
End-to-end firmware testing in ChromeOS relies on board-specific configuration files. Previously, those files were stored in Autotest. Now, they have been moved into a separate repository, fw-testing-configs, so that other testing frameworks (e.g. Tast, SerialTest) can access them too.
The design document for the new repository is at go/cros-fw-testing-configs.
All the config files are located at the top directory of the fw-testing-configs repository.
The fw-testing-configs repository currently has two checkouts in the ChromeOS manifest: one inside of Autotest, and one inside of tast-tests.
There is one config file for each platform, named as ${PLATFORM}.json
: for example, octopus.json
. There is also one special config file, DEFAULTS.json
, which contains default values and documentation for each attribute. (For now, platform names are defined according to mosys platform name
.)
Each config file should contain a single object whose fields override the values specified in DEFAULTS.json
. Any fields which do not have a corresponding value in DEFAULTS.json
will be ignored.
There are a few special fields to be aware of:
platform
(required): A string which should exactly match the config file’s basename (minus the .json
extension).parent
(optional): A string which can contain the name of a parent platform, whose fields will be inherited with lower precedence. See “Inheritance” below. Example: asuka.jsonmodels
(optional): An object which can contain the names of any models, whose fields will be inherited with higher precedence. See “Inheritance” below. Example: octopus.jsonThere is an inheritance model in these config files. In all cases, the most specific configuration is used:
[Model > ] Platform [ > Parent [...] ] > DEFAULTS
For each attribute that exists in DEFAULTS.json
(besides the documentation attributes):
models[${MODEL}]
, then that is the value that is used.${PLATFORM}.json
, then that is the value that is used.${PLATFORM}.json
specifies a parent configuration via the parent
attribute, then that is the value that is used.parent
attribute.DEFAULTS.json
is used.In Autotest, configs are loaded during FirmwareTest.initialize
. Config values can be accessed via self.faft_config.${ATTRIBUTE}
, such as self.faft_config.chrome_ec
.
In Tast, configs can be created via firmware.NewConfig
. In order to conform with Go’s style, attribute names are modified to MixedCaps. Config values can be accessed via cfg[${ATTRIBUTE}]
, such as cfg[ChromeEC]
.
When you create a new config for a new board, you should also register it in tast-tests/src/chromiumos/tast/remote/firmware/config.go
's configPlatforms. This is because datafiles used by Tast tests need to be explicitly declared. b/162253821 tracks finding a way to automate that.
Configs are now in a separate repository from Autotest or tast-tests. Thus, config edits now require a separate CL from Autotest/tast-tests edits. If you are accustomed to working with config files directly in Autotest, this is a slightly different workflow.
When you are editing config files, please be sure to run git commands from within the fw-testing-configs checkout. If you run git add .
or repo upload --cbr .
from within autotest/server/cros/faft/
, then your changes to the config files will not be captured.
If you are modifying both test files and config files, then you will need at least two CL’s: one for the test change, and one for the fw-testing-configs change. Consider also whether your change will impact the other testing repositories (Autotest, Tast, SerialTest): you might need to run tests or make changes there, too.
When submitting multiple CL’s like that, please use the Cq-Depend syntax as appropriate. If you don‘t use Cq-Depend, you risk the name of a config attribute changing while tests are still looking for the old name, and then tests will break. The reverse is a risk, too. You might need both CL’s to depend on each other. Note that this while this precaution mitigates risk, it does not fully eliminate risk: only one of the CL’s might get uploaded to the lab machines running Autotest/Tast, or one CL may be reverted without the other.