publish-to-BCR setup#313
Conversation
|
hmm, maybe this is a good opportunity to actually split this module into several ones (one per language). For example, Bazel's own use of remote-apis requires the Java gRPC targets, which aren't currently in this repo. I'll probably send another change tomorrow. |
| "name": "Xudong Yang" | ||
| }, | ||
| { | ||
| "github": "berksieker", |
There was a problem hiding this comment.
s/bergksieker/bergsieker/
| }, | ||
| { | ||
| "github": "berksieker", | ||
| "name": "Steven Bergsieker" |
There was a problem hiding this comment.
Should you add [email protected] as an email contact?
Can this be done orthogonally to getting this into bcr? Reclient and remote-apis-sdks's usage of this module would be greatly simplified if we can get this deployed to bcr. |
|
@Wyverald can we pick this up again? |
|
Sorry, I've been busy with managing Bazel's 8.0 release. Are you blocked on this change? I think you mentioned a few action items from your side in a previous email thread (including setting a new release schedule, etc). Are those completed already? |
We've agreed to move to a monthly release model, skipping months where there are no (meaningful) commits). We're also moving to date-based versioning. Ideally we'll cut the first such release around next Tuesday. Is it better to get this in place before that release, or do we need to wait for that release and use it as a baseline for the first BCR release the following month? |
Continue's @Wyverald's work from bazelbuild#313 to prepare for publishing to the Bazel Central Registry. Adapted some of the new workflows from bazel-contrib/rules_scala v7.2.4. - Adjusted some of the dependency versions in MODULE.bazel to be as low as possible, compatible with Bazel 7.x, and high enough to avoid warnings. - Adds the `test/bcr` Bazel module for the `.bcr/presubmit.yml` tests, to test building targets referenced from a client repo. - Adds a `.bazelci/presubmit.yml`, which also mirrors the jobs from `.bcr/presubmit.yml` (but with a `soft_fail`). - Adds `release.yml` and `release_prep.sh` to `.github/workflows` as well, which are prerequisites for the `publish-to-bcr.yml` workflow. - Updates several generated Go files after running `hooks/pre-commit`. The module builds with Bazel 7.x, 8.x, and 9.x (8.x and 9.x require `--incompatible_autoload_externally`, as noted in `.bazelrc`). It will _not_ currently build with `rolling` (10.0.0-pre.20260223.3) and `last_green` (bazelbuild/bazel@6a70e55) Bazels. Neither have `--incompatible_autoload_externally` any longer, and the unreleased `grpc` v1.80.0 contains the fix. Fixes bazelbuild#369. Closes bazelbuild#313. Co-authored-by: Xùdōng Yáng <[email protected]>
* Add the publish-to-bcr workflow, .bazelci config Continue's @Wyverald's work from #313 to prepare for publishing to the Bazel Central Registry. Adapted some of the new workflows from bazel-contrib/rules_scala v7.2.4. - Adjusted some of the dependency versions in MODULE.bazel to be as low as possible, compatible with Bazel 7.x, and high enough to avoid warnings. - Adds the `test/bcr` Bazel module for the `.bcr/presubmit.yml` tests, to test building targets referenced from a client repo. - Adds a `.bazelci/presubmit.yml`, which also mirrors the jobs from `.bcr/presubmit.yml` (but with a `soft_fail`). - Adds `release.yml` and `release_prep.sh` to `.github/workflows` as well, which are prerequisites for the `publish-to-bcr.yml` workflow. - Updates several generated Go files after running `hooks/pre-commit`. The module builds with Bazel 7.x, 8.x, and 9.x (8.x and 9.x require `--incompatible_autoload_externally`, as noted in `.bazelrc`). It will _not_ currently build with `rolling` (10.0.0-pre.20260223.3) and `last_green` (bazelbuild/bazel@6a70e55) Bazels. Neither have `--incompatible_autoload_externally` any longer, and the unreleased `grpc` v1.80.0 contains the fix. Fixes #369. Closes #313. Co-authored-by: Xùdōng Yáng <[email protected]> * Anoint Tiago Quelhas as maintainer Per @meteorcloudy's suggestion below. Replaces @Wyverald, as well as @bergsieker, who I understand isn't at Google anymore. - #370 (comment) * Anoint Fabian Meumertzheim as a maintainer Per @fmeum's acceptance via: - #370 (comment) --------- Co-authored-by: Xùdōng Yáng <[email protected]>
4 participants
@bergsieker: I volunteered you to be a module maintainer :) it should be very low maintenance, but let me know if you would rather not.
We can cut a release after this gets merged and watch it show up in BCR. (Note that we'll need to attach a release archive -- I can do this part.)