Move bazel-registry out of toolshed into envoyproxy/bazel-registry

[phlax]

Background

bazel-registry/ currently lives in this repo (issue was moved from toolshed). Leveraging toolshed's out-of-the-box CI has worked well as a bootstrap, but the registry's maintenance model is fundamentally different from toolshed's — in terms of the likely contribution profile (frequent, narrow, dependency-bump style changes from a wider set of people), and in terms of governance.

The registry was originally intended to live in envoyproxy/bazel-registry. This issue tracks moving it back there.

Moving it out also unlocks two things that are awkward to do here:

• Selective CI — today every change fans out over the whole module set. In a dedicated repo we can run only the targeted bits needed for the modules/versions actually touched, while also running a more extended BCR-like suite (on Envoy's RBE, as toolshed does).
• Publishing conventions — the registry needs rules that don't apply to toolshed, most notably that modules are immutable between versions.

Current state

• bazel-registry/modules/** — 80+ modules in standard BCR layout (metadata.json, <version>/source.json)
• .github/workflows/bazel-registry.yml — path-filtered trigger, discovers modules via find, matrixes over all modules
• .github/workflows/_bazel_registry.yml — per-module reusable workflow; matrixes over versions filtered to endswith(".envoy"), runs integrity check per source URL
• .github/workflows/registry_integrity.sh

CI today is integrity-only, and fans out over the entire registry rather than the changed subset.

Scope

1. Repo and content move

• Create envoyproxy/bazel-registry (does not currently exist)
• Move content with history preserved (git subtree split -P bazel-registry), not a flat copy
• Decide registry root layout — modules/ at repo root (canonical, plus bazel_registry.json) vs. retaining the bazel-registry/ prefix
• Deprecation stub / pointer left in toolshed
• Repoint consumers (--registry=) only once the new repo is populated and green

2. CI tier 1 — targeted, changed-modules-only

Port the existing integrity CI, but scoped:

• Diff origin/main...HEAD for modules/<mod>/<version>/** and emit a {module, version} matrix
• Continue consuming the toolshed actions (should-run, bson, jq) as pinned refs — dependency direction stays healthy
• Drop the .envoy-suffix version filter; in a dedicated registry all versions are in scope, but only changed ones run

3. CI tier 2 — extended, BCR-style verification on RBE

• Per changed module version: fetch source, apply patches, build the module against a scratch workspace that depends on it (BCR presubmit.yml style)
• Run on Envoy's RBE, mirroring toolshed's existing RBE plumbing, rather than fat GH runners
• Gated so metadata-only edits skip it

4. Publishing conventions — immutability enforcement

Modules are immutable between versions. CI must enforce this:

• For each modules/<mod>/<version>/ touched in a PR, determine whether <version> has already been released
• Released is defined by GitHub releases on envoyproxy/bazel-registry — authoritative for now
• If released → any modification (source.json, patches, MODULE.bazel, overlay files) is a hard failure, with a message directing the contributor to cut a new version instead
• If the version directory is added in the PR → allowed
• Companion checks:
  • metadata.json versions must be append-only
  • version directories may never be deleted
  • source.json integrity hashes must be sha256- SRI and must match the fetched artifact

5. Governance

• Separate CODEOWNERS / OWNERS from toolshed
• Lower-friction review path for routine bumps, backed by stronger mechanical enforcement in CI

Open questions

• Registry root layout — modules/ at repo root, or keep the bazel-registry/ prefix?
• Staging: single PR for the subtree move plus workflows, or prove the immutability check as a standalone PR against toolshed first?