Use the Publish to BCR reusable GitHub workflow

[mbland]

Description

Updates .github/workflows/release.yml and adds publish-to-bcr.yml for publishing to the Bazel Central Registry. Part of #1482 (originally broken out from #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.

Requires that the BCR_PUBLISH_TOKEN GitHub secret and the registry_fork specified in .github/workflows/publish-to-bcr.yml are in place.

See .bcr/README.md for all the details and references.

Motivation

This will enable automated publishing to https://registry.bazel.build/.

[mbland]

@simuons @liucijus I believe if you're OK with the transfer to the bazel-contrib org, per #1616, then we can apply this change first before merging (@meteorcloudy please check me on this):

diff --git i/.github/workflows/publish-to-bcr.yml w/.github/workflows/publish-to-bcr.yml
index 8f51b975..b5ebd076 100644
--- i/.github/workflows/publish-to-bcr.yml
+++ w/.github/workflows/publish-to-bcr.yml
@@ -28,7 +28,7 @@ jobs:
     with:
       tag_name: ${{ inputs.tag_name }}
       # bazelbuild/bazel-central-registry fork used to open a pull request.
-      registry_fork: simuons/bazel-central-registry
+      registry_fork: bazel-contrib/bazel-central-registry
     permissions:
       attestations: write
       contents: write

Also, it's essential that #1730 lands before we actually publish to the BCR.

[mbland]

@simuons @liucijus I set the registry_fork to bazel-contrib/bazel-central-registry in 4c4fcaf given @meteorcloudy's initiation of the transfer per #1616 (comment).

That just leaves creating the BCR_PUBLISH_TOKEN Personal Access Token in this repo. Then once this and #1730 (and possibly #1729) land, tagging v7.0.0 and pushing should work.

[mbland]

BTW, I just noticed another a bunch of similar errors in the CI build to the one I noted in 900847b earlier today:

WARNING: Download from
https://github.com/bufbuild/buf/releases/download/v1.27.0/protoc-gen-buf-lint-Windows-x86_64.exe
failed: class java.io.IOException GET returned 618 jwt:jwt-not-provided

Interesting that it looks like some invented a HTTP 618 error code somewhere.

[meteorcloudy]

I think the github infra is a bit unstable recently, I'm also seeing similar issue in bazel builds.

[alexeagle]

Note, I've populated a PAT for @aspect-marvin in the BCR_PUBLISH_TOKEN secret for this repo.
If you'd like to use a different identity, you can make a different PAT.

[mbland]

Oh, I was expecting @simuons or @liucijus to approve and merge this...I hope they don't mind in this case.

So to overstate the obvious to make absolutely sure I'm understanding correctly:

• Since this repo now belongs to bazel-contrib (Transfer rules_scala to bazel-contrib #1616), that gives anyone in the org rights to update its secrets.
• This repo now has a BCR_PUBLISH_TOKEN secret, so neither @simuons nor @liucijus need to update it if they're OK with the workflow publishing as @aspect-marvin.
• If they'd prefer not to use that identity, they can create a different Personal Access Token and replace BCR_PUBLISH_TOKEN with that one.

So @alexeagle: If they choose to replace BCR_PUBLISH_TOKEN, does that complicate the BCR publishing workflow in any way? My guess is no, but I don't want to assume.

And to be clear, I'd recommend against pushing a new tag to publish a new release until #1730 has landed.

[kormide]

If you are using @aspect-marvin as the PR author, I suggest setting draft: false (it defaults to true). Removes one step you have to do to merge the PR.

The draft option was added because authors can't approve their own PRs on the BCR. The BCR team wants to use clicking the "Ready for review" button as a mechanism to approve the PR in those cases.