-
Notifications
You must be signed in to change notification settings - Fork 554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rules_python build_file_generation integration tests on Ubuntu using minimum supported Bazel version is failing with "requirements_test on Bazel@HEAD #1520
Comments
… tests The Bazel downstream tests will use Bazel built at head, but the tests checking for support with the minimum Bazel version are specifically intended to only run with an older Bazel version. Work towards bazelbuild#1520
qq: did the system python version change on the build hosts? i.e. from python 3.8 to python 3.9? That looks to be a common diff showing up. (I'm not asking to undo that, it would just explain why this failure shows up). PR 1522 it out to partially address this -- many of those tests are trying to run bazel at head for the configs that should only be running Bazel 5.4. That will, at the least, skip those configs where it doesn't need to run. I'm still looking into the root cause. |
Ah, I think this is because of switching bzlmod on by default. Setting |
Bazel is enabling bzlmod by default, which means the examples need to be updated to be bzlmod compatible. Fixes bazelbuild#1520
Bazel is enabling bzlmod by default, which means the examples need to be updated to be bzlmod compatible. Fixes bazelbuild#1520
Bazel is enabling bzlmod by default, which means the examples need to be updated to be bzlmod compatible. Work towards #1520
Bazel at head has bzlmod enabled by default, so the example needs to be updated to work with bzlmod enabled. Work towards bazelbuild#1520
… with bzlmod Bazel at head enables bzlmod by default, so the tests must also be updated to be bzlmod compatible. Also makes compile_pip_requirements ignore its convenience symlinks. This allows locally running the "from external" workspace test even if the compile_pip_requirements workspace previously had convenience symlinks in it from other builds. Work towards bazelbuild#1520
Ok, I think I have PRs out for all the failures shown in that link. They're all fairly simple fixes. Most just need a MODULE.bazel file, a couple needed to change how they were finding files in runfiles. |
Bazel at head has bzlmod enabled by default, so the example needs to be updated to work with bzlmod enabled. Work towards #1520
… with bzlmod Bazel at head enables bzlmod by default, so the tests must also be updated to be bzlmod compatible. Also makes compile_pip_requirements ignore its convenience symlinks. This allows locally running the "from external" workspace test even if the compile_pip_requirements workspace previously had convenience symlinks in it from other builds. Work towards bazelbuild#1520
… with bzlmod (#1528) Bazel at head enables bzlmod by default, so the tests must also be updated to be bzlmod compatible. Also makes compile_pip_requirements ignore its convenience symlinks. This allows locally running the "from external" workspace test even if the compile_pip_requirements workspace previously had convenience symlinks in it from other builds. Work towards #1520
Bazel is enabling bzlmod by default, which means the examples need to be updated to be bzlmod compatible. Work towards #1520
All the PRs are merged. I think that fixes all the failures. @sgowroji let us know if more failures show up in subsequent downstream bazel runs |
Hi @rickeylev, Rules_Python is still failing with below errors with Bazel@HEAD. |
The build_file_generation example only supports workspace style builds. The bzlmod equivalent is in `examples/bzlmod_build_file_generation` Work towards bazelbuild#1520
Thanks. Looks like the same cause: bzlmod enabled by default. |
…xample The pip_repository_annoations example is workspace-only. Its equivalent functionality is demonstrated in examples/bzlmod with the whl_mods feature. Work towards bazelbuild#1520
Part of the pyc compilation process is to create a temporary file named `<name>.pyc.NNNN`, where `NNNN` is a timestamp. Once the pyc is entirely written, this file is renamed to the regular pyc file name. These files only exist for brief periods of time, but its possible for different threads/processes to see the temporary files when computing the glob() values. Later, since the file is gone, an error is raised about the file missing. PR bazelbuild#1266 mostly fixed this issue, except that the glob exclude for an interpreter runtime's files was behind the `ignore_root_user_error` flag, which meant it wasn't always applied. This changes it to always be applied, which should eliminate the failures. Fixes bazelbuild#1261 Work towards bazelbuild#1520
…1541) Part of the pyc compilation process is to create a temporary file named `<name>.pyc.NNNN`, where `NNNN` is a timestamp. Once the pyc is entirely written, this file is renamed to the regular pyc file name. These files only exist for brief periods of time, but its possible for different threads/processes to see the temporary files when computing the glob() values. Later, since the file is gone, an error is raised about the file missing. PR #1266 mostly fixed this issue, except that the exclude for the `.pyc.NNNN` files for an interpreter runtime's files was behind the `ignore_root_user_error` flag, which meant it wasn't always applied. This changes it to always be applied, which should eliminate the failures due to the missing NNNN files. Fixes #1261 Work towards #1520
Ok, all PRs merged. Fixed 🤞 |
https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3423#018b7e52-e06d-4e38-8577-97686d10d343
Platform : rules_python (build_file_generation integration tests on Ubuntu)
Logs:
Steps:
Autosheriff culprit : bazelbuild/bazel@32cc97e
CC Greenteam @comius
The text was updated successfully, but these errors were encountered: