DO NOT IMPORT: Use 0.29.1 in test

[meteorcloudy]

No description provided.

[jayconrod]

@meteorcloudy I started seeing test failures in CI on Windows yesterday. I assume this is related? My Windows laptop needs to be reinstalled, so I haven't investigated it yet.

The tests in question are based on go_bazel_test (see bazel_testing.go). Tests using this framework copy files into a test workspace, run bazel commands, and verify the results. The framework creates the test workspace under execroot and reuses it across tests to avoid large caches and slow startup times. Tests are tagged local and exclusive, so only one test runs at a time, without sandboxing.

I know this is pretty hacky and maybe not supported. If there's a simple fix or a better way in general to verify output of bazel commands within tests, please let me know.

[meteorcloudy]

Yes, this is for debugging that Windows issue. Turned out to be a bug in 1.0: bazelbuild/bazel#9995

[meteorcloudy]

@philwo is making a change to Bazelisk so that i can also point to a local Bazel binary. We can then make sure the rules_go tests invoke the Bazel built from HEAD instead of the latest stable version.

[jayconrod]

Thanks for looking into this!

Should the tests get the bazel binary from another place? Currently, they rely on PATH. I remember when we used Jenkins, there was a BAZEL environment variable. Is that still recommended?

[meteorcloudy]

I think it's fine to rely on bazel in PATH once bazelbuild/bazelisk#93 is deployed to CI. Because after that, Bazelisk will always point the same Bazel binary we are using to run the test.