[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
1 file changed
tree: d2beaebdee464f97e11fc22712a4175e8a09fb52
  1. ctf/
  2. git-hooks/
  3. infra/
  4. third_party/
  5. cts
  6. firmware
  7. flower
  8. jiri.lock
  9. MILESTONE
  10. minimal
  11. prebuilts
  12. README.md
  13. stem
  14. test_durations
  15. toolchain
README.md

Integration

This repository contains Fuchsia's Global Integration manifest files.

Making changes

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.

Obtaining the source

First install Jiri.

Next run:

$ jiri init
$ jiri import minimal https://fuchsia.googlesource.com/integration
$ jiri update

Third party

Third party projects should have their own subdirectory in ./third_party.