feat: automate publishing releases to Bazel Central Registry

[alexeagle]

Note, it's also required that someone with sufficient permissions "installs" the Publish-to-BCR GitHub app to this repo.
FYI @thesayyn

Fixes #14564

[alexeagle]

@zhangskz @googleberg looks like I can't get CI results for my PR since it originates from an untrusted fork. How should I proceed?
I plan to send more Bazel-related PRs so I'd like to have a solution that's not only specific to this one.

[alexeagle]

https://github.com/protocolbuffers/protobuf/blob/main/.github/workflows/test_runner.yml#L8-L10

In these cases, we
require a special "safe for tests" tag to be added to the pull request before
we start testing. This will be immediately removed, so that further commits
require their own stamp to test.

Looks like every time I push a commit, I'll have to ask a Googler to add a tag on my PR. Doesn't sound very productive, but I guess it's a start.

[zhangskz]

Hi Alex, we should have just granted you some additional permissions that should allow you to push to a dev branch in the repo instead to bypass the "safe for test" tag requirement (or at least add the tag yourself for PRs from your fork). Let me know if that works to help speed things up a bit.

[zhangskz]

Do you have instructions on what you need regarding installing the Publish-to-BCR app?

[alexeagle]

@zhangskz yes, could you go to https://github.com/apps/publish-to-bcr and click Configure, then add it to this repository?

[zhangskz]

@zhangskz yes, could you go to https://github.com/apps/publish-to-bcr and click Configure, then add it to this repository?

Done.

[zhangskz]

Hi Alex, have you been able to get unblocked on testing this? Let me know if this is ready for review, or if there's anything we can do to help unblock here..

[aran]

Would be useful to merge this!

[alexeagle]

Thanks for the ping @aran - taking another look

[alexeagle]

@zhangskz I'd like to understand why the BCR entries are accumulating a bunch of patches:
https://github.com/bazelbuild/bazel-central-registry/tree/main/modules/protobuf/23.1/patches

It seems like the protobuf project is forking, these patches represent some other branch where bzlmod-related changes are stacking up, while main represents WORKSPACE. Is this an intentional strategy, or an accident?

I think there are a couple sane paths forward:

1. instead of adding patches for publishing, just make those changes in this repo. I'll send a trial PR to see if it gets accepted by maintainers before I sink a bunch of time into this.
2. stop exposing protobuf as a Bazel project at all. protobuf already ships binary tools for each release, and rules_proto can provide all the starlark code to fetch these binaries from the GitHub releases page and make them work for Bazel users. This way the protobuf team can stop having this Bazel support drag.

[alexeagle]

looks like I have to close this to re-open a PR that comes from the upstream rather than my fork.

[zhangskz]

1. I think the equivalent of these patches can and should be introduced into the protobuf repo itself -- this is likely just an artifact of lack of MODULE.bzl file / BCR support and current releases being contributed by third parties.
2. We still want to have protobuf to have first-class bazel support, esp. for development / testing, though indeed users should generally be using our published release from Github. Are you suggesting a way to provide Bazel support for users via our Github binary releases and reducing some maintenance burden, or dropping this support entirely?