[roll] Roll fuchsia [bazel] Add export_bazel_host_test.py script This adds a new script that can export a Bazel host test target and its runtime requirements to the Ninja build directory, without using an intermediate GN target. The script takes a command and one or more Bazel target patterns as input. The patterns are used to find all Bazel test targets from a tree of dependencies, e.g. `//build/bazel/host_tests/...` will find all tests under the given package. The `list` command can be used to generate tests.json for each test target found from the patterns. One difference from the GN-generated entries is that each "test.label" value will begin with an `@` to indicate it is a Bazel label, and will not include a GN toolchain suffix. For example a valid label would be `@//build/bazel/host_tests/cc_tests:static_test`. The `export` command will populate $FUCHSIA_BUILD_DIR/bazel_host_tests/ with symlinks and files corresponding to each test target. IMPORTANT: The only way to correctly run each test is to invoke then from the Fuchsia build directory, with a path like `bazel_host_tests/<package>/<name>`. More exactly, some tests will work just fine when invoked from any other directory, but some others will not. Which ones depend on implementation details of language-specific runfiles libraries and or Bazel rules. For example, after this command: ``` python3 build/bazel/scripts/export_host_tests.py \ export //build/bazel/host_tests/... ``` Launching this test from the Fuchsia directory works: ``` out/default/bazel_host_tests/build/bazel/host_tests/py_tests/test_with_py_library ``` But launching that other test from the same location does not: ``` out/default/bazel_host_tests/build/bazel/host_tests/py_tests/test_with_py_binary ``` While launching it from the build directory does: ``` (cd out/default && bazel_host_tests/build/bazel/host_tests/py_tests/test_with_py_binary) ``` In practice, `fx test` always runs tests from the Fuchsia build directory, or the equivalent `testrunner` sandbox directory when running on bots through `botanist`, so this should only affect developers who are used to invoke tests directly. Would it be too annoying, we may want to generate launcher scripts that change the current directory before launching the real entry point in the future. Note that for now, nothing uses this script. Future CLs will add changes that: - Modify `build/regenerator.py` to augment `tests.json` with Bazel-specific host test targets. This will require a Bazel query to be performed at `fx gen` time, which may slow down this step considerably, so this will initially be an optional feature triggered by an `args.gn` flag, to avoid annoying developers until this can be sped up. - Ensure `fx test` can detect Bazel-specific labels in tests.json and properly rebuild them by invoking fx-bazel directly for them instead of fx-build. The `path` attribute in the tests.json file will ensure it will be launched properly. - Modify infra scripts and tools to support the Bazel-specific tests. Current understanding is that this would require minimal work as the exported tests and corresponding tests.json entries match what is expected by their implementation (the GN label doesn't seem to be used except for debug messages). Original-Bug: 349341932 Original-Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/1198666 Original-Revision: a5d6b695bd5a962d5d38d6d81a2bf4ff56d8ed4d GitOrigin-RevId: 8ac0091065cd97ce91b76acc3f64c1cddda7d5ea Change-Id: Id62c63aefcf071c594efb6e908e888c55b8b89ad
This repository contains Fuchsia's Global Integration manifest files.
All changes should be made to the internal version of this repository. Our infrastructure automatically updates this version when the internal one changes.
Currently all changes must be made by a Google employee. Non-Google employees wishing to make a change can ask for assistance in one of the communication channels documented at get involved.
First install Jiri.
Next run:
$ jiri init $ jiri import minimal https://fuchsia.googlesource.com/integration $ jiri update
Third party projects should have their own subdirectory in ./third_party.