tests: make toolchain tests run in the same build instead of bazel-in-bazel integration tests#2095
Conversation
|
Ok, CI Should be happy now. @aignas Do we happen to have existing code to map the Over in tests/toolchains/defs.bzl, I'm generating a target for each version. However, not all versions support all platforms, e.g., 3.8.10 doesn't support windows. So I need to generate e.g. That config setting generation looks awfully familiar, as do the platform 2-tuple strings (e.g. "aarch64-apple-darwin", "x86_64-unknown-linux-gnu"). |
aignas
left a comment
There was a problem hiding this comment.
LGTM, thanks for simplifying!
| dev_dependency = True, | ||
| ) | ||
| dev_python.rules_python_private_testing( | ||
| register_all_versions = True, |
There was a problem hiding this comment.
Something like this could be super useful in registering minor_major versions by default.
There was a problem hiding this comment.
Yeah, I had a similar thought. I'll post in slack.
| break | ||
| if register_all: | ||
| arg_structs.extend([ | ||
| _create_toolchain_attrs_struct(python_version = v) |
This PR uses the `flag_values` from the platform definitions for the toolchains so that in the future we can distinguish between `musl` and `glibc` toolchains in our tests. For now the change is no-op. As part of this change we are also registering the coverage tools so that we can run `bazel coverage` with no errors. See comment on #2095.
This changes the //tests/toolchains tests to run in the same Bazel build instance instead of
being bazel-in-bazel integration tests. This is done by using a transition to set
the python version to match the desired toolchain.
This makes running the tests much cheaper -- there were 37 sub-bazel processes being
started (one for each python version), which was very expensive. Debugging is also much easier because they aren't part of a bazel-in-bazel invocation.