← work

Architect and principal author

tomato-bazel

A self-hosted Bazel plane — RBE cluster, module registry, and 56 rulesets behind SPARQL gates.

The build plane beneath fastverk: a bzlmod registry publishing 84 modules across 480 versions, a Buildbarn remote-execution cluster modelled as Kubernetes CRDs, and an admission gate that projects the module graph into RDF and enforces invariants as SPARQL queries where the returned rows are the counterexample.</parameter> <parameter name="story">This is what happens when a monorepo is decomposed into a constellation of independently versioned modules and the seams have to be held by machines rather than convention. At the centre is a self-hosted bzlmod registry carrying 84 modules — 56 of them `rules_*` — across 480 published versions, released through a purpose-built Rust CLI that computes source integrity itself. Admission used to be audited by weekly cron, which is how, in the workflow's own words, "135 findings accrued across 300-odd published versions"; it now happens at pull-request time through `gate`, a Rust pipeline that evaluates MODULE.bazel files, runs minimal version selection, projects the resulting facts into Turtle, and runs one SPARQL query per invariant. Ten such gates exist today — unpinned overrides in published modules, atoms selected at multiple versions, toolchain-registration leakage, unnamespaced extension repos, metadata drift — and a gate is one query file plus one target, so adding an invariant needs no Rust rebuild. Because the corpus is not yet clean, the merge check runs as a ratchet rather than a gate: it projects both the pull request and its base, compares per-gate counts, and fails only on regression, which stops things getting worse instead of demanding zero first. The execution side is a Buildbarn cluster expressed as `RbeCluster` and `WorkerPool` custom resources, with a CI action that lets a workflow name only its tenant and receive its endpoint, credential and exec-property flags from the platform at runtime rather than transcribing them. The rulesets themselves are deeper than wrappers: `rules_lean` reuses mathlib's upstream olean cache and adds a test that audits a theorem's transitive axiom set through `Lean.collectAxioms`, catching a dependency that silently introduces `Classical.choice`; `rules_cloudformation` generates roughly 1,582 typed rules, one per AWS resource type, from the pinned upstream schema; `rules_tla` runs TLC model-checking as ordinary `bazel test` targets.

BazelbzlmodStarlarkRustGoLean 4RDFSPARQLSHACLApache JenaBuildbarnREAPIKubernetesCRDsHelmCloudFormationEKSProtobufprostTLA+GitHub Actions