| commit | 9cd16f5857132fbacb74d602e43f52c86d92620c | [log] [tgz] |
|---|---|---|
| author | Greg Edelston <gredelston@google.com> | Thu Nov 12 17:50:28 2020 |
| committer | Commit Bot <commit-bot@chromium.org> | Sat Nov 14 00:55:28 2020 |
| tree | 2e760f7f436cdabd34823c89428fc61d8e7bda2b | |
| parent | 252bca32512be13d78d75152ee9e3a3aef3487ad [diff] |
fwtc: Create script to calculate a board's JSON Currently, the ultimate fw-testing-config JSON is determined at runtime based on logic that is duplicated in both FAFT and Tast. This has two unfortunate effects: 1. Duplicated logic is hard to maintain, and can easily lead to inconsistent errors. 2. There is no easy way for a developer to see what the config values are for a given platform. A first step toward solving both of those problems is to write a script in fw-testing-configs that will calculate the final configs for a platform. Also re-runs consolidate.py, because https://crrev.com/c/2519483 did not re-run the script for a late patch-set. BUG=b:173118460 BUG=b:173118890 TEST=platform_json_unittest.py TEST=platform_json.py fievel (has multiple inheritance) TEST=platform_json.py octopus -m bobba360 (has model override) TEST=platform_json.py octopus --condense-output Change-Id: Id9927efe8f3730ad3e02a5986ad8c0b443f86512 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/fw-testing-configs/+/2534754 Tested-by: Greg Edelston <gredelston@google.com> Reviewed-by: Andrew Luo <aluo@chromium.org> Commit-Queue: Andrew Luo <aluo@chromium.org> Auto-Submit: Greg Edelston <gredelston@google.com>
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 are also one special config file, DEFAULTS.json and CONSOLIDATED.json. DEFAULTS.json contains default values and documentation for each attribute. CONSOLIDATED.json is a generated file, containing the config data from all the other JSON files.
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.CONSOLIDATED.json is a generated script containing the data from all other JSON files. This allows Tast tests to access the config data. Thus, it is important to keep CONSOLIDATED.json up-to-date.
When you make a change to fw-testing-configs JSON, before you upload, be sure to run ./consolidate.py (with no command-line args). This will update CONSOLIDATED.json. Amend your change to include the update CONSOLIDATED.json, and then re-upload.
A preupload hook will verify that your CONSOLIDATED.json is up-to-date.
fw-testing-configs is a separate repository from both Autotest and tast-tests. Thus, edits to fw-testing-configs require a separate CL from edits to Autotest and tast-tests. 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.
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].