[Bazel CI] Multiple failures in integration tests #2469
Comments
|
Fixed by bazelbuild/continuous-integration#2141 *rules_python (RBE) I don't think this is a rules_python issue? We just use the Bazel CI provided RBE configs. Fixed
Caused by odd sys.argv0 change to paths under bazel 9; see other comment. Fixed
I thought I had fixed this previously? Well, I'll have to look again. Fixed
ERROR: error loading package 'external': Both --enable_bzlmod and --enable_workspace are disabled, but one of them must be enabled to fetch external dependencies.` I think this is because that example disable bzlmod, and with newer versions workspace must be explicitly enabled. Fix should be to modify its bazelrc to enable workspace. Fixed
I had to fix a similar error in another test. Fix is to switch to using |
Bazel 9 won't support workspace builds, so skip them in the Bazel@head pipeline. The bzlmod equivalents of these examples is covered elsewhere. Along the way, enable workspace by default in the examples for a bit of futureproofing. Work towards #2469
Ok, this one is weird -- the version of rules_python being used, in rules_python itself, is version 0.28.0. Reproing this is easy: |
This seems to be because The test is a shell script that runs a python program. It looks like this: Where On Bazel 7, when Python sees Later in the bootstrap logic, a regex is looking for It's weird that changing the Bazel version seems to cause this. Everything else seems to be the same (Python version, bash version). |
This is for overall code hygiene, but also because it seems to make some progress on Bazel 9 being able to load files in WORKSPACE mode (something about defs.bzl triggers loading more symbols which can't be found) Work towards bazelbuild#2469
…zel 9 (#2481) When the shell test invokes the python binary, it uses a combination of forward slashes and backslashes. Under Bazel 9, that mixture of slashes is preserved. This later breaks a regex that looks for the OS-specific path separator. To fix, normalize forward slashes to the OS path separator. Oddly, it's not Bazel that is passing the mixture of slashes (it's the shell), but behavior seems to vary based on which version of Bazel is used. Along the way, copy the nicer `print_verbose` function from the stage2 bootstrap into the old bootstrap. It prints debug information in a nicer format. Work towards #2469
Update code and examples to load the object-specific bzl files instead of the generic `defs.bzl`. This is mostly for code hygiene, but came out of trying to diagnose why Bazel 9 workspace builds kept erroing with defs.bzl somehow related. Removing the internal usages of defs.bzl doesn't seem to fully fix it, but does seem to eliminate some errors, make some progress, and narrow down what's going on. Work towards #2469
I think I figured this out: defining the rules_python_internal repo was happening too late in the workspace processing. And then, i think bazel_tools ended up defining rules_python with an old version, somehow. In any case, defining rules_python_internal earlier seems to fix this. Another work around was to do |
…zel 9 (bazelbuild#2481) When the shell test invokes the python binary, it uses a combination of forward slashes and backslashes. Under Bazel 9, that mixture of slashes is preserved. This later breaks a regex that looks for the OS-specific path separator. To fix, normalize forward slashes to the OS path separator. Oddly, it's not Bazel that is passing the mixture of slashes (it's the shell), but behavior seems to vary based on which version of Bazel is used. Along the way, copy the nicer `print_verbose` function from the stage2 bootstrap into the old bootstrap. It prints debug information in a nicer format. Work towards bazelbuild#2469
…d#2483) Update code and examples to load the object-specific bzl files instead of the generic `defs.bzl`. This is mostly for code hygiene, but came out of trying to diagnose why Bazel 9 workspace builds kept erroing with defs.bzl somehow related. Removing the internal usages of defs.bzl doesn't seem to fully fix it, but does seem to eliminate some errors, make some progress, and narrow down what's going on. Work towards bazelbuild#2469
rules_proto is deprecated and recent versions simply forward onto com_google_protobuf. Older versions (e.g. 6.x used by us today), however, use the rules_proto or native (Bazel builtin) implementation. When those older versions are used with Bazel 9, which has removed various proto things, errors occur. To fix, switch to using com_google_protobuf directly. More recent versions of rules_proto just forward onto com_google_protobuf anyways, so this just removes the extra dependency and having to deal with WORKSPACE setup. Work towards #2469
Ok, I give up trying to find a clean fix. Defining rules_python_internal helps, as did removing some unnecessary loads of bazel_tools in rules_python. However, I can't get past these errors with a nice fix: Where My best guess about that cause is a java toolchain in bazel_tools needs @bazel_tools//tools/jdk:BUILD, which loads rules_python, and then autoloading defines rules_python using rules_python 0.28.0. I can't fix those loads, though, so I'll just use the local_repository() trick I mentioned before. |
…#2501) Building with Bazel 9 using WORKSPACE results in an odd error that `PyInfo` isn't defined. Oddly, the error refers to `rules_python/python/private/reexports.bzl` for rules_python 0.28.0. This seems to only happen when the main module is rules_python. While Bazel 9 is supposed to drop workspace support, I've been advised it's better to keep testing WORKSPACE support until closer to when Bazel 9 fully removes it. My best guess about what's happening is Bazel's autoloading is triggering and somehow defining rules_python before it's recognized that the main module is rules_python. The autoloading appears to be triggered, eventually, by things in bazel_tools loading rules_python. While removing unnecessary `@bazel_tools` loads in rules_python helps, the particular case I can't find a clean solution to is when `@@rules_java//toolchains:toolchain_java11_definition` causes rules_python to be loaded. This appears to end up loading rules_python via `@bazel_tools//tools/jdk:BUILD`, which has has some py rules defined in it. To fix/work around this issue, `local_repository` can be used to define the `rules_python` repo before autoloading happens. This appears to take precedence over whatever logic autoloading has. Work towards #2469
|
I think everything here is fixed. The issue with the flag added by bazel ci was fixed by bazelbuild/continuous-integration#2141 |
CI: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/4313#01939501-8a44-41dc-a7b2-fb29fd9561d3
Platform: Ubuntu
Logs:
Culprit:
Steps:
CC Greenteam @Wyverald
The text was updated successfully, but these errors were encountered: