767e094fb8
Updates run_tests to use cargo style target triples for specifying build targets. A simple 'aarch64' or 'armhf' was nice while we just had linux builds. We now are looking at windows and possibly different toolchain options (e.g. msvc vs gnu), so our old system was getting confusing and inconsistent. We used to have some special handling for adding wrappers to test runs for emulation (e.g. wine, qemu). That logic has been moved into TestTarget which now contains not just where to run the test but also how. Supported are armhf/aarch64 qemu as well as wine64. The CLI has been updated to match and now uses the build-target argument instead of arch. The following combinations have been tested (though not all combinations actually pass all tests, which is a separate issue). ./tools/run_tests ./tools/run_tests --target=host --build-target=x86_64-unknown-linux-gnu ./tools/run_tests --target=host --build-target=armhf ./tools/run_tests --target=host --build-target=aarch64 ./tools/run_tests --target=host --build-target=mingw64 ./tools/run_tests --target=vm:aarch64 ./tools/run_tests --target=vm:aarch64 --build-target=armhf BUG=b:233914170 TEST=See above Change-Id: Ic6dbb5b39788e2573714606d3bb0e7c712032d91 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3739240 Tested-by: kokoro <noreply+kokoro@google.com> Commit-Queue: Dennis Kempin <denniskempin@google.com> Reviewed-by: Daniel Verkamp <dverkamp@chromium.org> |
||
|---|---|---|
| .. | ||
| config | ||
| recipe_modules/crosvm | ||
| recipes | ||
| .gitignore | ||
| README.md | ||
| README.recipes.md | ||
| recipes.py | ||
WIP Luci Infrastructure
This directory contains the configuration and build recipes run by our luci infrastructure for CI and presubmit testing. This is currently a work in progress.
See Kokoro configs for the actively used presubmit system.
Note: Luci applies config and recipes changes asynchronously. Do not submit changes to this directory in the same commit as changes to other crosvm source.
Recipes
Recipe Documentation
A few links to relevant documentation needed to write recipes:
Luci also provides a User Guide and Walkthrough for getting started with recipes.
Running recipe tests
Recipes must have 100% code coverage to have tests pass. Tests can be run with:
cd infra && ./recipes.py test run
Most tests execute a few example invocations, record the commands that would be executed and compare
them to the json files in *.expected. This allows developers to catch unwanted side-effects of
their changes.
To regenerate the expectation files, run:
cd infra && ./recipes.py test train
Then verify the git diff to make sure all changes to outcomes are intentional.
Testing recipes locally
We try to build our recipes to work well locally, so for example build_linux.py can be invoked in the recipe engine via:
cd infra && ./recipes.py run build_linux
When run locally, recipes that check out crosvm, will run against the current HEAD of the main branch.
The recipe will run in the local infra/.recipe_deps/recipe_engine/workdir directory and is
preserved between runs in the same way data is preserved on bots, so incremental builds or the use
of cached files can be tested.
Testing recipes on a bot (Googlers only)
Note: See internal crosvm/infra documentation on access control.
Some things cannot be tested locally and need to be run on one of our build bots. This can be done with the led tool.
To test changes to an existing recipe, you need to find a previous build that you want to use as a template and get it's buildbucket id:
Then git commit your recipe changes locally and run:
led get-build $BBID | led edit-recipe-bundle | led launch
get-build will download and output the job definition, led edit-recipe-bundle will upload a
version of your local recipes and update the job definition to use them. The resulting job
definition can then be launched on a bot via led launch.