After the fix to tests for #98, tests may fail when run directly via bazel test as opposed to through the runner script run_tests.sh. I see two modes of failure:
When --incompatible_use_python_toolchains is disabled, //tests:version_test may fail if /usr/bin/env python is a Python 2 interpreter, due to bazelbuild/bazel#4815.
When --incompatible_use_python_toolchains is enabled, the default toolchain's py[2|3]wrapper.sh script is added to runfiles, causing brittle assertions in many tests to fail. This doesn't appear under run_tests.sh because it has its own custom toolchain that adds no runfiles.
This isn't an immediate problem because CI still passes, but it is annoying for the developer workflow. For 1), I'd just wait for the toolchain flag flip. For 2), the test assertions should be made more robust. In the meantime, use run_tests.sh instead of bazel test //....
After the fix to tests for #98, tests may fail when run directly via
bazel test
as opposed to through the runner scriptrun_tests.sh
. I see two modes of failure:When
--incompatible_use_python_toolchains
is disabled,//tests:version_test
may fail if/usr/bin/env python
is a Python 2 interpreter, due to bazelbuild/bazel#4815.When
--incompatible_use_python_toolchains
is enabled, the default toolchain'spy[2|3]wrapper.sh
script is added to runfiles, causing brittle assertions in many tests to fail. This doesn't appear underrun_tests.sh
because it has its own custom toolchain that adds no runfiles.This isn't an immediate problem because CI still passes, but it is annoying for the developer workflow. For 1), I'd just wait for the toolchain flag flip. For 2), the test assertions should be made more robust. In the meantime, use
run_tests.sh
instead ofbazel test //...
.