Consider publishing grpc-gateway to Bazel Central Registry

[hharrisd]

We maintain an SDK that depends on grpc-gateway. We're encountering challenges with Bazel's module system, as override directives only work in root modules.

Publishing grpc-gateway to BCR would:

• Eliminate the need for overrides
• Ensure consistent builds across all dependent projects
• Reduce maintenance overhead for downstream users
• Align with Bazel's recommended dependency management practices

We're willing to help with the BCR publication process if you're interested. Would you consider this addition to improve the experience for grpc-gateway users?

[johanbrandhorst]

Thanks for your issue. We've talked about doing this before so it's definitely something I'd consider. Please feel free to open a PR. I want to make sure this doesn't unduly add to the maintenance burden of this repository, so I'd want publishing to the registry to happen automatically when a new release is built. I'm happy to registry any accounts and populate secrets necessary for CI. CC @AlejoAsd who helped add our bzlmod support.

[hharrisd]

Hi @johanbrandhorst, thank you for your answer.

I have been reading about publishing modules in BCR. The simplest and most recommended method is to use Publish to BCR.

Process description

Publish to BCR is a GitHub app that mirrors releases of your Bazel ruleset to the Bazel Central Registry.

The goal is that when a grpc-gateway version is released, the app will create a PR in a forked BCR repository.

Initially, the released version is sanity-checked: the app runs a presubmit job, which builds and runs tests on module targets. If the tests are successful, a PR is built for the BCR.

IMPORTANT: running the presubmit job will require CI credits. Are you OK with adding this extra pipeline?

Process diagram

Configuration Steps

1. Install and configure Publish to BCR for two repositories.
   • This repository grpc-gateway.
   • A fork of bazelbuild/bazel-central-registry.
   • We need from the grpc-gateway team to proceed with this configuration.
2. Add templates to construct a new BCR PR after a release.
   • I'm working on these templates. I will create a PR for this and add @AlejoAsd as reviewer.
   • In this step, we need the grpc-gateway team to provide the maintainer's data (name, email, and GitHub user).
3. Cut a release. A pull request will be opened against the BCR.

The steps are described in the Publish to BCR repo.

[johanbrandhorst]

Thanks for looking into this. The process sounds good to me - just one concern. Can we run the presubmit as part of our CI, to ensure there's no risk of making a release that can't pass the presubmit and make it to the BCR? I would hate to have to re-release something just because it failed the presubmit.

Where would the bazel-central-registry fork live? I can create it in grpc-ecosystem, but is it a necessity? I'm happy to volunteer as the project maintainer for the purpose of creating the PRs against a user.

[hharrisd]

Thank you for your answer.

Regarding your questions:

1. Can we run the presubmit as part of our CI, to ensure there's no risk of making a release that can't pass the presubmit and make it to the BCR?

   Presubmit should include essential build and test targets used to verify a module version. For instance, I propose running tests in your root and examples folders targets.

   Likewise, a set of validations is checked during presubmit. A tool in the BCR repo can run those presubmit validations locally. Maybe it could be integrated into your CI.

2. Where would the bazel-central-registry fork live? I can create it in grpc-ecosystem, but is it a necessity?

   According to Publish to BCR:

   A fork of bazelbuild/bazel-central-registry. The fork can be in the same GitHub account as your ruleset or in the release author's personal account. If you use release automation and the release author is the github-actions bot, then the fork must be in ruleset's account unless you override the releaser.

[johanbrandhorst]

Cool, I think our existing Bazel CI jobs probably already satisfy the presubmit requirements. I'm also happy to create the BCR fork in this org, maybe it can serve other repositories in this org too.