🤖 wip feat!: publish to BCR as rilla_rules_tf

[dominics]

🤖 LLM generated description follows

Builds everything needed to publish this fork to the Bazel Central Registry, without publishing anything. There is no workflow that calls publish-to-bcr, and the registry PR is opened by hand.

Why a new name

The BCR already carries rules_tf, filed by upstream with repository: ["github:yanndegat/rules_tf"]. Three separate mechanisms stop a fork publishing under it: the source-URL check rejects an archive hosted anywhere else, the existing maintainer would have to approve the PR, and the registry is add-only with no "inactive upstream" escape hatch available (upstream is active). BCR's own maintainer playbook prescribes the remedy - prepend the org, so nobody mistakes a fork for the community standard ruleset.

Only the registry identity moves. repo_name stays rules_tf, which is the name the module calls itself, so all 61 internal @rules_tf// references are untouched and no .bzl file changes in this PR. That matters more than convenience: several of those references are templated into generated toolchain repositories, where a relative // label would resolve to the generated repo rather than to us.

Consumers do change. They must rename the module in bazel_dep and move labels to @rilla_rules_tf//. Passing repo_name = "rules_tf" to bazel_dep keeps the old labels resolving, which lets core-infra and webrtc-sim land the label change separately from the dependency change if they want to. That escape hatch is deliberately not in the README, which shows one canonical form.

Why a release asset

The BCR grades archive stability by URL path alone: on github.com only a /releases/download/ asset counts, and the tarball GitHub generates for a tag is flagged unstable regardless of its bytes. Publishing without an asset means asking a reviewer to waive that check on every version bump. release.yml now builds one with git archive and attaches it. The prefix matches GitHub's own for the same tag, so strip_prefix stays valid either way, and .gitattributes decides what the archive omits.

Why the presubmit target list is not //...

The registry builds a module as a dependency of a synthesized root module, and two things that hold locally stop holding there: dev_dependency modules are not resolved, and --deleted_packages (which hides the child modules under tests/) lives in .bazelrc, which Bazel reads only for a root workspace.

This was verified rather than guessed, by reproducing that setup locally - an empty module depending on this one through archive_override, pointed at the built release archive. @rilla_rules_tf//... fails on rules_shell; the four listed scopes plus two exclusions build 34 targets clean. The two exclusions are aliases into the dev-only multitool hub. Removing the git toolchain (below) is why this needs two exclusion lines rather than upstream's -//tf/toolchains/git:* carve-out.

Scope note

The first commit removes tf/toolchains/git as well as tf/releasing. The git toolchain existed solely to serve the releasing package - its only consumers were tf/releasing/git.bzl and its own implementation files, and MODULE.bazel registered it dev-only with a comment naming //tf/releasing as the reason. Removing one without the other would leave a toolchain, an extension and a registration block with nothing to serve. Neither known consumer references either package at origin/main.

Sequencing

This is expected to land after #18, #19, #26 and #27. It edits tests/bcr*/MODULE.bazel, which those branches are actively reshaping, so conflicts there are expected and should be resolved in favour of their fixture changes plus this PR's two-line rename.

2.2.0 is a placeholder. Nothing is released here; confirm the number when the tag is actually cut.

Follow-ups, not in this PR

• Consumer migration in core-infra and webrtc-sim.
• Cutting the tag and hand-opening the registry PR. A first entry needs a BCR maintainer to apply presubmit-auto-run and approve, plus CLA signing.
• Attestations. BCR marks them experimental, and only accepts source-archive attestations produced by bazel-contrib/.github's release_ruleset.yaml, which would mean restructuring release.yml around a hard-coded script path and a draft-then-finalize dance. Not worth it for a first entry.

Test plan

• bazel test //... (15 pass), bazel test //tests:integration_tests (4 pass), bazel test //tests:facts_test, bazel run //lint:buildifier.check, //.github:actionlint.
• purl compared across the change: pkg:bazel/rules_tf on main, pkg:bazel/rules_tf@2.2.0 here.
• Archive built from branch HEAD (not an existing tag - git archive reads export-ignore from the tree being archived, so an older tag would prove nothing): .github excluded, tests/bcr/MODULE.bazel and patches/ retained, root MODULE.bazel byte-identical to the checked-in one.
• tests/bcr builds 56 targets and passes 14 tests from inside the extracted archive, confirming its local_path_override(path = "../..") resolves there.

🤖 Generated with Claude Code