Automate publishing to BCR whenever we cut a release

[smolkaj]

In #572, @Eshaan-byte is adding P4Runtime 1.4.1 to the BCR -- our first entry in the BCR! However, for subsequent P4Runtime releases, we would really like to automate this workflow. According to Gemini, setting that up is generally relatively straightforward (see below).

There is once complication: unless we first address #571, we would need a patch file, which will be annoying to maintain. So we may want to combine the two thing in one.

cc @jonathan-dilorenzo @matthewtlam, since #571 is a breaking change from a build perspective, this will require some updates across our code bases. Should be very amenable to automation though.

---

You can fully automate this using the publish-to-bcr GitHub Action (maintained by bazel-contrib). This is the standard community tool used by most major projects (like rules_python, rules_go, etc.).

This automation replaces the manual process of calculating integrity hashes, patching files, and opening PRs. It ensures the MODULE.bazel consistency rules you asked about are perfectly met every time.

Step 1: Prerequisites

Before automating, you need two things:

1. Fork the Registry: Fork the [bazel-central-registry](https://github.com/bazelbuild/bazel-central-registry) repository to your personal or organization GitHub account (e.g., my-org/bazel-central-registry).
2. Create a Token: Create a generic GitHub Personal Access Token (Classic) with repo and workflow scopes.

• Why? The bot needs permission to push a branch to your fork of the registry and open a PR against the upstream BCR. The default GITHUB_TOKEN cannot access other repositories.
• Save this token as a Repository Secret in your project (e.g., BCR_PUBLISH_TOKEN).

Step 2: Create the Workflow

Create a file at .github/workflows/release.yml.
The modern standard is to use the Reusable Workflow pattern, which handles all the setup, archiving, and attestation logic for you.

name: Release to BCR

on:
  release:
    types: [published]

jobs:
  publish-bcr:
    # Use the reusable workflow from bazel-contrib
    uses: bazel-contrib/publish-to-bcr/.github/workflows/publish.yaml@v3
    with:
      # The name of your module as defined in MODULE.bazel
      module_name: my_module_name
      
      # The tag that triggered this release (e.g., "v1.2.3")
      tag_name: ${{ github.event.release.tag_name }}
      
      # Your fork of the BCR where the bot will push the branch
      registry_fork: my-org/bazel-central-registry
      
      # Optional: If you use a strip_prefix in your source archive
      # strip_prefix: my-module-1.2.3 
      
    secrets:
      # The PAT you created in Step 1
      token: ${{ secrets.BCR_PUBLISH_TOKEN }}

Step 3: Add a presubmit.yml

The BCR requires a presubmit.yml file in your submission to tell their CI how to verify your module. You should add this file to your source repository (usually at the root), and the automation will automatically include it in the package.

File: presubmit.yml

matrix:
  platform:
    - ubuntu2004
    - macos
    - windows
tasks:
  verify_build:
    name: Verify Build
    platform: ${{ platform }}
    build_targets:
      - //...

How the Automation Works

When you click "Publish Release" on GitHub:

1. Trigger: The action triggers on the new tag.
2. Archive: It downloads your source code (mirroring exactly what users will download).
3. Consistency Check: It extracts the MODULE.bazel from that archive and compares it to your repository's version (handling the validation rule we discussed previously).
4. Submission: It pushes a new branch to your BCR fork (e.g., my-org/bazel-central-registry) containing the metadata and source.json.
5. PR: It opens a Pull Request against bazelbuild/bazel-central-registry on your behalf.

Handling Patches

If your module requires patches to work on the BCR (e.g., swapping a git_repository for a bazel_dep that only exists in the registry version), you can configure the workflow to apply them automatically:

    with:
      # ... other inputs ...
      patch_paths: |
        patches/001-fix-deps.patch
        patches/002-add-module-dot-bazel.patch

This effectively "swaps" the MODULE.bazel during the release process, ensuring the registry gets the BCR-compatible version while your repo keeps the dev-compatible version.

---