Repository intelligence

bazel-contrib/publish-to-bcr

GitHub

A reusable GitHub Actions workflow that automates mirroring and publishing releases of Bazel rulesets to the Bazel Central Registry (BCR).

CLOUDM0N decision
Trust FAIL · 35/100
Good fit if

Bazel ruleset maintainers wanting to automate mirroring their ruleset releases to the Bazel Central Registry (BCR).

Watch out for

Fine-grained Personal Access Tokens (PATs) are not fully supported because they cannot directly open pull requests against public repositories.

Practical intelligence

What matters before you adopt it

Problem it solves

The manual overhead and potential errors involved in mirroring Bazel ruleset releases, generating compliance attestations, applying patches, and opening pull requests against the Bazel Central Registry.

Best for
Bazel ruleset maintainers wanting to automate mirroring their ruleset releases to the Bazel Central Registry (BCR).
Teams managing ruleset repositories with multiple modules that are versioned together or separately.
Main trade-offs
Fine-grained Personal Access Tokens (PATs) are not fully supported because they cannot directly open pull requests against public repositories.
Attestation uploading requires using the specific 'bazel-contrib release_ruleset' workflow; source archive attestations produced in other ways will be rejected by the BCR.
Does not automatically finalize releases when utilizing attestations and immutable releases, requiring manual finalization or an additional workflow job.
Why it stands out
Supports patching rulesets and submodules using patch files in -p1 format during publication.
Handles complex multi-module repositories with customizable module root configurations and tag prefixes.
Permits opening publishing pull requests in draft mode to allow ruleset owners to self-approve entries via the 'Ready for review' button.
Trust & CVEs

Security evidence without the noise

Trust remains a decision signal; CVEs and scanner evidence explain what is driving the risk.

Security findings
3
CLOUDM0N scanner findings
Critical
1
High
0
Medium
2
Low
0
View trust evidence & security findings
Why this score
No trust rationale was stored for this scan.
CLOUDM0N findings
CRITICAL
Private-key material appears to be committed in executable/config scope. 1 sample match(es) found.
MEDIUM
Dynamic code execution pattern detected. 2 sample match(es) found.
MEDIUM
The project can spawn operating-system processes; review command construction and input handling. 3 sample match(es) found.
Architecture from code10 modules · 4 edges
Structural evidence

Modules and dependency edges extracted from repository code. This is code evidence, not README inference.

Code files
48
Modules
10
Dependency edges
4
Core modules
(root)
4 files
src/application
9 files
src/domain
29 files
src/infrastructure
4 files
src/test
tests
2 files
Dependency flow
src/applicationsrc/domain
src/applicationsrc/infrastructure
src/domainsrc/infrastructure
src/domainsrc/test
Detected languages
TypeScript · JavaScript · Shell · C
Detected frameworks
Axios · Jest · NestJS
Architecture evidence details
flowchart TD
    %% publish-to-bcr — high-level architecture (DRAFT, refine me)
    n0["(root) · 4 files"]
    n1["src/application · 9 files"]
    n2["src/domain · 29 files"]
    n3["src/infrastructure · 4 files"]
    n4["src/test · tests · 2 files"]
    n1 --> n2
    n1 --> n3
    n2 --> n3
    n2 --> n4
    class n4 test
    classDef test fill:#499894,color:#ffffff,stroke:#397975
Evidence, security & integrations
Integrations
Bazel Central Registry (BCR)GitHub ActionsBzlmodbazel-contrib release_ruleset workflow
Security notes
Fine-grained PATs should be created for the owner of the registry fork if used instead of classic PATs.
Using classic PATs requires 'workflow' and 'repo' permissions.
Build attestations verify the provenance of release archives, helping secure the supply chain.
For immutable releases, keeping the release as a draft during publishing ensures that attestations are safely uploaded to the draft before finalization.
Still unknown
The README does not provide technical details on how the template files are parsed or what specific structure config.yml must have.
It does not provide specific error codes or troubleshooting steps for when the workflow fails to push to the registry fork.
It does not state any resource or runner environment limits (like CPU or memory requirements) for running the GitHub Actions job.
Adoption guidance
Adopt if
+ You want to automate the publication of your Bzlmod-compatible Bazel rulesets to the Bazel Central Registry.
+ You want to integrate security features like release artifact attestations into your Bazel release pipeline using the bazel-contrib ecosystem.
Avoid if
You cannot use Classic Personal Access Tokens (PATs) and cannot accept the manual PR step required when using fine-grained PATs.
Your ruleset is not prepared for Bzlmod or does not follow the Bzlmod User Guide.
How it works & getting started
How it works
1.The user sets up a GitHub Actions workflow containing the reusable publish workflow.
2.The workflow is triggered automatically after a release or manually via workflow_dispatch, receiving the release tag name.
3.The workflow references the reusable template and uses a configured Classic PAT or machine user token to push changes to a registry fork.
4.It downloads artifacts from the release step or run, including any specified patches under .bcr/patches.
5.The workflow opens a pull request (optionally as a draft) against the Bazel Central Registry to complete the publication.
Getting started
Prepare your ruleset for bzlmod by following the Bzlmod User Guide.
Include the publish-to-bcr template files in your ruleset repository.
Create a GitHub Actions workflow file, typically named .github/workflows/publish.yaml.
Create a Classic Personal Access Token (PAT) with 'workflow' and 'repo' permissions.
Save the token as BCR_PUBLISH_TOKEN in your repository or organization secrets.
Agent handoff
Use with any agent
JSON API