Bazel green build CI job now fails persistently due to rules_java versioning #1625

mbland · 2024-10-18T14:00:58Z

All CI jobs except "Bazel green head" pass for my PRs working towards #1482 with the following error:

bazel --nosystem_rc --nohome_rc info
ERROR: Failed to load Starlark extension '@@rules_java//toolchains:toolchain_utils.bzl'.
Cycle in the workspace file detected. This indicates that a repository is used prior to being defined.
The following chain of repository dependencies lead to the missing definition.
 - @@rules_java
This could either mean you have to add the '@@rules_java' repository with a statement like `http_archive` in your WORKSPACE file (note that transitive dependencies are not added automatically), or move an existing definition earlier in your WORKSPACE file.
ERROR: cannot load build configuration key because of this cycle
Traceback (most recent call last):
  File "bazelci.py", line 4588, in <module>
    sys.exit(main())
  File "bazelci.py", line 4556, in main
    execute_commands(
  File "bazelci.py", line 1321, in execute_commands
    bazel_version = print_bazel_version_info(bazel_binary, platform)
  File "bazelci.py", line 1623, in print_bazel_version_info
    execute_command(
  File "bazelci.py", line 2750, in execute_command
    return subprocess.run(
  File "/usr/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['bazel', '--nosystem_rc', '--nohome_rc', 'info']' returned non-zero exit status 2.

After reviewing my notes from cd22d88, under Bump to rules_java 7.9.0 for Bazel 7 compatibility, it seems like our WORKSPACE builds can't be compatible with Bazel 6/7 and Bazel 8 at the same time. The basic issue is that for rules_java > 7.9.0, the WORKSPACE prefix in Bazel 6/7 causes Java toolchains to register under a different type than what the rules are expecting later. This issue doesn't affect Bzlmod builds.

Would it be possible to disable the "Bazel green head" builds until the Bzlmod compatibility lands, and then reenable that build with Bzlmod enabled?

The text was updated successfully, but these errors were encountered:

simuons · 2024-10-21T08:40:36Z

Hi, @mbland, I've changed last_green to latest in #1627
I understand it's not a robust solution, but I hope it will hold until bzlmod lands into rules_scala.
I'll ask you to rebase your PRs so I could merge them after review.

mbland · 2024-10-21T14:41:45Z

Sounds good, thanks! Did you want to keep this issue open until that point, or close it now, and/or open a new one to switch it back at that point?

simuons · 2024-10-23T05:39:00Z

Let's keep it open as actual issue is not fixed.

mbland · 2024-10-23T13:56:07Z

BTW, I pinpointed in a Bazel Slack thread with @shs96c the builds before and after the rules_java 7.9.0 bump from #1619:

And just to mention it explicitly here: bazelbuild/bazel: Remove rules_java_builtin in WORKSPACE prefix "fixes" the problem in Bazel 8, enabling WORKSPACE builds to use rules_java > 7.9.0. But as mentioned already, doing so would break WORKSPACE for Bazel 6 and 7, which still have rules_java_builtin in their WORKSPACE prefix.

mbland · 2024-11-26T17:58:00Z

I just discovered some further complications, noted in #1652, that may prevent building with the latest green Bazel build. ~~, or require breaking WORKSPACE compatibility permanently.~~

Update: We could actually maintain WORKSPACE compatibility on Bazel 8 and rules_java 8, but it would no longer work with Bazel 6 or 7. If/when we decide to update for Bazel 8 compatibility, we could reenable this latest green head build, but probably not before.

Another update: I've created the bazel-8-compatibility working branch in my rules_scala fork with the commit message for mbland@ebe714d describing the current build breakages, which are the same under WORKSPACE and Bzlmod.

Note that this branch/commit is based on my bzlmod working branch, not the current upstream master branch.

This fixes CI builds because Bazel 8.0.0 just came out, but `rules_scala` is not yet Bazel 8 compatible, causing `latest Bazel` builds to fail. Part of bazelbuild#1625 and bazelbuild#1652. - https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#how-does-bazelisk-know-which-bazel-version-to-run

mbland · 2024-12-09T20:59:31Z

I just filed #1671 to fix the latest Bazel builds in the wake of Bazel 8 being released an hour ago (which I noticed after pushing a commit to #1660) by setting the build to 7.x instead of latest.

On the bright side, per my work on both #1482 and #1652, I have a branch incorporating both Bzlmod and Bazel 8 compatibility changes that builds with Bazel 8.0.0, the latest Bazel 9 rolling release, and the latest Bazel green HEAD. So once that Bazel 8 release lands, we can restore the last_green build (or add it, keeping latest as well, as there might be utility to having both).

This fixes CI builds because Bazel 8.0.0 just came out, but `rules_scala` is not yet Bazel 8 compatible, causing `latest Bazel` builds to fail. Part of bazelbuild#1625 and bazelbuild#1652. - https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#how-does-bazelisk-know-which-bazel-version-to-run

This fixes CI builds because Bazel 8.0.0 just came out, but `rules_scala` is not yet Bazel 8 compatible, causing `latest Bazel` builds to fail. Part of #1625 and #1652. - https://github.com/bazelbuild/bazelisk?tab=readme-ov-file#how-does-bazelisk-know-which-bazel-version-to-run

All but finishes bazelbuild#1482, barring the release and publication to the Bazel Central Registry. Closes bazelbuild#1625. New `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch comprise the bulk of the commit. The empty `WORKSPACE.bzlmod` files ensure that Bzlmod won't evaluate the existing `WORKSPACE` files. Reenables the `last_green` Bazel build in CI. Other than that, these new files comprise the most significant part of the change: - `.bazelignore` - `.bcr/*` - `scala/extensions/config.bzl` - `scala/extensions/deps.bzl` - `scala/private/extensions/dev_deps.bzl` - `scala/private/macros/bzlmod.bzl` `config.bzl`, `deps.bzl`, and `dev_deps.bzl` are thoroughly tested by existing tests. These new test files thoroughly test the helpers from `scala/private/macros/bzlmod.bzl` specifically: - scala/private/macros/test/... - test/shell/test_bzlmod_macros.sh The pattern employed throughout the new module extensions is explained in the `scala/private/macros/bzlmod.bzl` docstring. Adding `test/shell/test_bzlmod_macros.sh` also precipitated adding a new `assert_matches` helper to `test/shell/test_helper.sh`. `test/shell/test_helper.sh` also introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. "Publish to BCR" configuration in the `.bcr` directory comes from: - https://github.com/bazel-contrib/publish-to-bcr/tree/main/templates The bazel-contrib/publish-to-bcr README contains further guidance on configuring the app. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. Once the Publish to BCR GitHub app is ready, we can use it to publish a new version to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, barring the release and publication to the Bazel Central Registry. Closes bazelbuild#1625. New `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch comprise the bulk of the commit. The empty `WORKSPACE.bzlmod` files ensure that Bzlmod won't evaluate the existing `WORKSPACE` files. Reenables the `last_green` Bazel build in CI. Other than that, these new files comprise the most significant part of the change: - `.bazelignore` - `.bcr/*` - `scala/extensions/config.bzl` - `scala/extensions/deps.bzl` - `scala/private/extensions/dev_deps.bzl` - `scala/private/macros/bzlmod.bzl` `config.bzl`, `deps.bzl`, and `dev_deps.bzl` are thoroughly tested by existing tests. These new test files thoroughly test the helpers from `scala/private/macros/bzlmod.bzl` specifically: - scala/private/macros/test/... - test/shell/test_bzlmod_macros.sh The pattern employed throughout the new module extensions is explained in the `scala/private/macros/bzlmod.bzl` docstring. Adding `test/shell/test_bzlmod_macros.sh` also precipitated adding a new `assert_matches` helper to `test/shell/test_helper.sh`. `test/shell/test_helper.sh` also introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. Added `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh` to ensure `MODULE.bazel` files remain consistent. "Publish to BCR" configuration in the `.bcr` directory comes from: - https://github.com/bazel-contrib/publish-to-bcr/tree/main/templates The bazel-contrib/publish-to-bcr README contains further guidance on configuring the app. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. Once the Publish to BCR GitHub app is ready, we can use it to publish a new version to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, barring the release and publication to the Bazel Central Registry. Closes bazelbuild#1625. New `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch comprise the bulk of the commit. The empty `WORKSPACE.bzlmod` files ensure that Bzlmod won't evaluate the existing `WORKSPACE` files. Reenables the `last_green` Bazel build in CI. Other than that, these new files comprise the most significant part of the change: - `.bazelignore` - `.bcr/*` - `scala/extensions/config.bzl` - `scala/extensions/deps.bzl` - `scala/private/extensions/dev_deps.bzl` - `scala/private/macros/bzlmod.bzl` `config.bzl`, `deps.bzl`, and `dev_deps.bzl` are thoroughly tested by existing tests. These new test files thoroughly test the helpers from `scala/private/macros/bzlmod.bzl` specifically: - scala/private/macros/test/... - test/shell/test_bzlmod_macros.sh The pattern employed throughout the new module extensions is explained in the `scala/private/macros/bzlmod.bzl` docstring. Adding `test/shell/test_bzlmod_macros.sh` also precipitated adding a new `assert_matches` helper to `test/shell/test_helper.sh`. `test/shell/test_bzlmod_macros.sh` also introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. Added `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh` to ensure `MODULE.bazel` files remain consistent. "Publish to BCR" configuration in the `.bcr` directory comes from: - https://github.com/bazel-contrib/publish-to-bcr/tree/main/templates The bazel-contrib/publish-to-bcr README contains further guidance on configuring the app. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. Once the Publish to BCR GitHub app is ready, we can use it to publish a new version to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, barring the release and publication to the Bazel Central Registry. Closes bazelbuild#1625. New `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch comprise the bulk of the commit. The empty `WORKSPACE.bzlmod` files ensure that Bzlmod won't evaluate the existing `WORKSPACE` files. Reenables the `last_green` Bazel build in CI. Other than that, these new files comprise the most significant part of the change: - `.bazelignore` - `.bcr/*` - `scala/extensions/config.bzl` - `scala/extensions/deps.bzl` - `scala/private/extensions/dev_deps.bzl` - `scala/private/macros/bzlmod.bzl` `config.bzl`, `deps.bzl`, and `dev_deps.bzl` are thoroughly tested by existing tests. These new test files thoroughly test the helpers from `scala/private/macros/bzlmod.bzl` specifically: - scala/private/macros/test/... - test/shell/test_bzlmod_macros.sh The pattern employed throughout the new module extensions is explained in the `scala/private/macros/bzlmod.bzl` docstring. Adding `test/shell/test_bzlmod_macros.sh` also precipitated adding a new `assert_matches` helper to `test/shell/test_helper.sh`. `test/shell/test_bzlmod_macros.sh` also introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. Added `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh` to ensure `MODULE.bazel` files remain consistent. Adds `bazel clean --expunge_async` to tests that create temporary repos and the `test_cleanup.sh` script to reclaim disk space. "Publish to BCR" configuration in the `.bcr` directory comes from: - https://github.com/bazel-contrib/publish-to-bcr/tree/main/templates The bazel-contrib/publish-to-bcr README contains further guidance on configuring the app. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. Once the Publish to BCR GitHub app is ready, we can use it to publish a new version to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, barring the release and publication to the Bazel Central Registry. Closes bazelbuild#1625. New `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch comprise the bulk of the commit. The empty `WORKSPACE.bzlmod` files ensure that Bzlmod won't evaluate the existing `WORKSPACE` files. Reenables the `last_green` Bazel build in CI. Other than that, these new files comprise the most significant part of the change: - `.bazelignore` - `.bcr/*` - `scala/extensions/config.bzl` - `scala/extensions/deps.bzl` - `scala/extensions/protoc.bzl` - `scala/private/extensions/dev_deps.bzl` - `scala/private/macros/bzlmod.bzl` `config.bzl`, `deps.bzl`, and `dev_deps.bzl` are thoroughly tested by existing tests. These new test files thoroughly test the helpers from `scala/private/macros/bzlmod.bzl` specifically: - scala/private/macros/test/... - test/shell/test_bzlmod_macros.sh The pattern employed throughout the new module extensions is explained in the `scala/private/macros/bzlmod.bzl` docstring. Adding `test/shell/test_bzlmod_macros.sh` also precipitated adding a new `assert_matches` helper to `test/shell/test_helper.sh`. `test/shell/test_bzlmod_macros.sh` also introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. Added `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh` to ensure `MODULE.bazel` files remain consistent. Adds `bazel clean --expunge_async` to tests that create temporary repos and the `test_cleanup.sh` script to reclaim disk space. "Publish to BCR" configuration in the `.bcr` directory comes from: - https://github.com/bazel-contrib/publish-to-bcr/tree/main/templates The bazel-contrib/publish-to-bcr README contains further guidance on configuring the app. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. Once the Publish to BCR GitHub app is ready, we can use it to publish a new version to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazelbuild#1625. The module extensions and underlying helper macros comprise the most significant part of the change. The extensions provide a thin layer over the existing `WORKSPACE` API. The `scala/private/macros/bzlmod.bzl` docstring explains the common pattern employed throughout. - `scala/extensions/config.bzl`: invokes `scala_config()` - `scala/extensions/deps.bzl`: invokes `scala_toolchains()` - `scala/extensions/protoc.bzl`: invokes `scala_protoc_toolchains()` - `scala/private/extensions/dev_deps.bzl`: internal testing dependencies - `scala/private/macros/bzlmod.bzl`: module extension helper macros Existing tests thoroughly validate `config.bzl`, `deps.bzl`, `dev_deps.bzl`, and `protoc.bzl`. `test/shell/test_bzlmod_macros.sh` tests the helpers from `scala/private/macros/bzlmod.bzl` using the new test files from `scala/private/macros/test/...`. Most of the new files are essentially boilerplate: - Adds `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch to the main repo and every nested repo. - Adds empty `WORKSPACE.bzlmod` files to ensure that Bzlmod won't evaluate the `WORKSPACE` files. These changes update CI and the release workflow: - Sets `--noenable_workspace` in `.bazelrc` and `tools/bazel.rc.buildkite`. - Reenables the `last_green` Bazel build in `.bazelci/presubmit.yml`. - Adds `.github/workflows/publish-to-bcr.yml` and `.bcr/*` for publishing to the Bazel Central Registry. `.github/workflows/release.yml` invokes this new workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. All other changes: - Adds `.bazelignore` to work around bazelbuild/bazel#22208. - Adds `assert_matches` to `test/shell/test_helper.sh` for use in `test/shell/test_bzlmod_macros.sh`. - `test/shell/test_bzlmod_macros.sh` introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. - Adds `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh`. - Adds `bazel clean --expunge_async` to tests that create temporary repos. - Adds the `test_cleanup.sh` script to reclaim disk space. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. It also ensures that new changes are compatible with the `last_green` build of Bazel, and enables publishing releases to the Bazel Central Registry. Per the (prereleased) "Publish to BCR" workflow setup instructions linked from `.bcr/README.md`, we need to create: - a fork of `bazelbuild/bazel-central-registry` (which I've proactively referred to as `simuons/bazel-central-registry`) - a personal access token with "workflow" and "repo" permissions, saved as `PUBLISH_TOKEN` in the BCR fork (under "Settings > Secrets and variables > Actions") Once these items are ready, we can push a release tag to publish the first `rules_scala` Bazel module to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazelbuild#1625. The module extensions and underlying helper macros comprise the most significant part of the change. The extensions provide a thin layer over the existing `WORKSPACE` API. The `scala/private/macros/bzlmod.bzl` docstring explains the common pattern employed throughout. - `scala/extensions/config.bzl`: invokes `scala_config()` - `scala/extensions/deps.bzl`: invokes `scala_toolchains()` - `scala/extensions/protoc.bzl`: invokes `scala_protoc_toolchains()` - `scala/private/extensions/dev_deps.bzl`: internal testing dependencies - `scala/private/macros/bzlmod.bzl`: module extension helper macros Existing tests thoroughly validate `config.bzl`, `deps.bzl`, `dev_deps.bzl`, and `protoc.bzl`. `test/shell/test_bzlmod_macros.sh` tests the helpers from `scala/private/macros/bzlmod.bzl` using the new test files from `scala/private/macros/test/...`. Most of the new files are essentially boilerplate: - Adds `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch to the main repo and every nested repo. - Adds empty `WORKSPACE.bzlmod` files to ensure that Bzlmod won't evaluate the `WORKSPACE` files. These changes update CI and the release workflow: - Sets `--noenable_workspace` in `.bazelrc` and `tools/bazel.rc.buildkite`. - Reenables the `last_green` Bazel build in `.bazelci/presubmit.yml`. - Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` and `.bcr/*` for publishing to the Bazel Central Registry. `release.yml` now uses the `release_ruleset` workflow from `bazel-contrib/.github`, which does everything `release.yml` did previously and adds SLSA provenance attestations. `release.yml` then invokes the new `publish-to-bcr.yml` workflow after publishing a successful release to GitHub. Based on aspect-build/rules_lint#498 and aspect-build/rules_lint#501. See `.bcr/README.md`. All other changes: - Adds `.bazelignore` to work around bazelbuild/bazel#22208. - Adds `assert_matches` to `test/shell/test_helper.sh` for use in `test/shell/test_bzlmod_macros.sh`. - `test/shell/test_bzlmod_macros.sh` introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. - Adds `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh`. - Adds `bazel clean --expunge_async` to tests that create temporary repos. - Adds the `test_cleanup.sh` script to reclaim disk space. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. It also ensures that new changes are compatible with the `last_green` build of Bazel, and enables publishing releases to the Bazel Central Registry. Per the (prereleased) "Publish to BCR" workflow setup instructions linked from `.bcr/README.md`, we need to create: - a fork of `bazelbuild/bazel-central-registry` (which I've proactively referred to as `simuons/bazel-central-registry`) - a personal access token with "workflow" and "repo" permissions, saved as `PUBLISH_TOKEN` in the BCR fork (under "Settings > Secrets and variables > Actions") Once these items are ready, we can push a release tag to publish the first `rules_scala` Bazel module to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazelbuild#1625. The module extensions and underlying helper macros comprise the most significant part of the change. The extensions provide a thin layer over the existing `WORKSPACE` API. The `scala/private/macros/bzlmod.bzl` docstring explains the common pattern employed throughout. - `scala/extensions/config.bzl`: invokes `scala_config()` - `scala/extensions/deps.bzl`: invokes `scala_toolchains()` - `scala/extensions/protoc.bzl`: invokes `scala_protoc_toolchains()` - `scala/private/extensions/dev_deps.bzl`: internal testing dependencies - `scala/private/macros/bzlmod.bzl`: module extension helper macros Existing tests thoroughly validate `config.bzl`, `deps.bzl`, `dev_deps.bzl`, and `protoc.bzl`. `test/shell/test_bzlmod_macros.sh` tests the helpers from `scala/private/macros/bzlmod.bzl` using the new test files from `scala/private/macros/test/...`. Most of the new files are essentially boilerplate: - Adds `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch to the main repo and every nested repo. - Adds empty `WORKSPACE.bzlmod` files to ensure that Bzlmod won't evaluate the `WORKSPACE` files. These changes update CI and the release workflow: - Sets `--noenable_workspace` in `.bazelrc` and `tools/bazel.rc.buildkite`. - Reenables the `last_green` Bazel build in `.bazelci/presubmit.yml`. - Adds `.bcr/*` for publishing to the Bazel Central Registry using the Publish to BCR GitHub app. See `.bcr/README.md`. All other changes: - Adds `.bazelignore` to work around bazelbuild/bazel#22208. - Adds `assert_matches` to `test/shell/test_helper.sh` for use in `test/shell/test_bzlmod_macros.sh`. - `test/shell/test_bzlmod_macros.sh` introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. - Adds `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh`. - Adds `bazel clean --expunge_async` to tests that create temporary repos. - Adds the `test_cleanup.sh` script to reclaim disk space. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. It also ensures that new changes are compatible with the `last_green` build of Bazel, and enables publishing releases to the Bazel Central Registry. Per the (prereleased) "Publish to BCR" workflow setup instructions linked from `.bcr/README.md`, we need to create: - a fork of `bazelbuild/bazel-central-registry` (which I've proactively referred to as `simuons/bazel-central-registry`) - a personal access token with "workflow" and "repo" permissions, saved as `PUBLISH_TOKEN` in the BCR fork (under "Settings > Secrets and variables > Actions") Once these items are ready, we can push a release tag to publish the first `rules_scala` Bazel module to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

All but finishes bazelbuild#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazelbuild#1625. The module extensions and underlying helper macros comprise the most significant part of the change. The extensions provide a thin layer over the existing `WORKSPACE` API. The `scala/private/macros/bzlmod.bzl` docstring explains the common pattern employed throughout. - `scala/extensions/config.bzl`: invokes `scala_config()` - `scala/extensions/deps.bzl`: invokes `scala_toolchains()` - `scala/extensions/protoc.bzl`: invokes `scala_protoc_toolchains()` - `scala/private/extensions/dev_deps.bzl`: internal testing dependencies - `scala/private/macros/bzlmod.bzl`: module extension helper macros Existing tests thoroughly validate `config.bzl`, `deps.bzl`, `dev_deps.bzl`, and `protoc.bzl`. `test/shell/test_bzlmod_macros.sh` tests the helpers from `scala/private/macros/bzlmod.bzl` using the new test files from `scala/private/macros/test/...`. Most of the new files are essentially boilerplate: - Adds `MODULE.bazel` files mirroring existing `WORKSPACE` configurations and copies of the `protobuf` toolchainization patch to the main repo and every nested repo. - Adds empty `WORKSPACE.bzlmod` files to ensure that Bzlmod won't evaluate the `WORKSPACE` files. These changes update CI: - Sets `--noenable_workspace` in `.bazelrc` and `tools/bazel.rc.buildkite`. - Reenables the `last_green` Bazel build in `.bazelci/presubmit.yml`. - Replaces `//tools:lint_check` in CI with `test_lint.sh`, which now runs `test/shell/test_bzlmod_tidy.sh` to lint `MODULE.bazel` files. All other changes: - Adds `.bazelignore` to work around bazelbuild/bazel#22208. - Adds `.bcr/` files for publishing to the Bazel Central Registry using the Publish to BCR GitHub app. See `.bcr/README.md`. - Adds `assert_matches` to `test/shell/test_helper.sh` for use in `test/shell/test_bzlmod_macros.sh`. - `test/shell/test_bzlmod_macros.sh` introduces a mechanism for automatically finding and skipping tests, documented in the comment at the bottom of the file. - Adds `bazel mod tidy` checks to `test_lint.sh` and `test_version.sh`. - Adds `bazel clean --expunge_async` to tests that create temporary repos. - Adds the `test_cleanup.sh` script to reclaim disk space. --- This change enables Bazel 7 and 8 users to migrate their `rules_scala` dependency from `WORKSPACE` to `MODULE.bazel` whenever they're ready. It also ensures that new changes are compatible with the `last_green` build of Bazel, and enables publishing releases to the Bazel Central Registry. Per the "Publish to BCR" workflow setup instructions linked from `.bcr/README.md`, we need to: - create a fork of `bazelbuild/bazel-central-registry` (presumably `simuons/bazel-central-registry`) - configure the "Publish to BCR" app for both that fork and `bazelbuild/rules_scala` Once these items are ready, we can push a release tag to publish the first `rules_scala` Bazel module to https://registry.bazel.build/. At that point, we can close bazelbuild#1482.

This was referenced Oct 18, 2024

Update test scripts for Bzlmod compatibility #1622

Merged

Support Bzlmod and add rules_scala to bazel-central-registry #1482

Open

simuons mentioned this issue Oct 21, 2024

Build against latest bazel version instead of last_green #1627

Merged

mbland mentioned this issue Nov 26, 2024

Bazel 8.0.0 compatibility #1652

Closed

mbland mentioned this issue Dec 9, 2024

Set latest Bazel build to 7.x after 8.0.0 release #1671

Merged

mbland linked a pull request Mar 26, 2025 that will close this issue

Enable Bzlmod #1722

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bazel green build CI job now fails persistently due to rules_java versioning #1625

Bazel green build CI job now fails persistently due to rules_java versioning #1625

mbland commented Oct 18, 2024 •

edited

Loading

simuons commented Oct 21, 2024

mbland commented Oct 21, 2024

simuons commented Oct 23, 2024

mbland commented Oct 23, 2024

mbland commented Nov 26, 2024 •

edited

Loading

mbland commented Dec 9, 2024

Bazel green build CI job now fails persistently due to rules_java versioning #1625

Bazel green build CI job now fails persistently due to rules_java versioning #1625

Comments

mbland commented Oct 18, 2024 • edited Loading

simuons commented Oct 21, 2024

mbland commented Oct 21, 2024

simuons commented Oct 23, 2024

mbland commented Oct 23, 2024

mbland commented Nov 26, 2024 • edited Loading

mbland commented Dec 9, 2024

mbland commented Oct 18, 2024 •

edited

Loading

mbland commented Nov 26, 2024 •

edited

Loading