chore: fix new BCR release #501
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kormide
approved these changes
Mar 17, 2025
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 23, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 23, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 24, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 25, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 25, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 26, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 26, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 26, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 26, 2025
All but finishes bazel-contrib#1482, save for publication of the first `rules_scala` release to the Bazel Central Registry. Closes bazel-contrib#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 bazel-contrib#1482.
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Mar 31, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 15, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 21, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 21, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 21, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 27, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 27, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 27, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 28, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
mbland
added a commit
to mbland/rules_scala
that referenced
this pull request
Apr 29, 2025
Updates `.github/workflows/release.yml` and adds `publish-to-bcr.yml` for publishing to the Bazel Central Registry. Part of bazel-contrib#1482 broken out from bazel-contrib#1722. `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`. --- Extracting this from bazel-contrib#1722 makes that pull request more focused, and prevents holding it up based on any discussion around these workflow changes in particular. It's also unclear if the infrastructure will be in place to support these workflows before we're ready to publish the first `rules_scala` module. Though these workflows will supersede the Publish to BCR app, it may take some time to resolve slsa-framework/slsa-verifier#840. aspect-build/rules_lint#508, @alexeagle manually triggered a workflow run based on these workflows, which generated an attestation: - https://github.com/aspect-build/rules_lint/actions/runs/14095611671 - https://github.com/aspect-build/rules_lint/attestations/5857159 Here are some examples of GitHub's attestation UI in general: - https://github.com/aspect-build/rules_lint/attestations And some relevant GitHub docs: - https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow - https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs#secrets-context - https://docs.github.com/en/actions/sharing-automations/reusing-workflows#passing-inputs-and-secrets-to-a-reusable-workflow - https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onworkflow_callsecrets
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We now use the reusable workflow rather than a configured GitHub App.
bazelbuild/bazel-central-registry#4060 was created by manually triggering the workflow from this PR branch.
Changes are visible to end-users: no