-
Notifications
You must be signed in to change notification settings - Fork 11
Open
Description
🧱 Unify Tooling into a Single Bazel Module
🎯 Goal
Create a single cohesive Bazel module for internal tooling to simplify versioning, improve traceability, and reduce user-facing complexity.
✅ Current Situation
- Tooling is spread across one central
tooling
repository and multiple subdirectories. - Each tool defines its own
MODULE.bazel
, with its own versioning scheme. - The version tags in the
tooling
repository do not reflect the versions or states of individual tools. - Our custom
bazel_registry
is highly confusing: each tool references a different tooling release.
🚀 Solution
- Consolidate all internal tools into a single Bazel module.
- Use one central
MODULE.bazel
that includes all tools as packages. - Adopt a unified versioning scheme for the entire tooling module.
- Align release tags with the actual tooling content and state.
🛠️ Concrete Tasks
- Create a new unified
MODULE.bazel
in the tooling repo. - Move or link existing tools into the new module structure.
- Update
bazel_registry
to point to the unified tooling module. - Deprecate existing per-tool modules in the
bazel_registry
. See https://github.com/bazelbuild/bazel-central-registry/blob/44c3233b36523f70232676c40251e1b816d9aeb8/metadata.schema.json#L59 - Update CI/CD to release the unified module.
- Communicate the change to downstream users.
- Update CI/CD to test the unified module instead of individual tools.
- Ensure integration tests are still working, by using the new tooling module.
- Update README file(s), e.g. keep individual READMEs, but add a top level one.
🔄 Considered Alternatives
Alternative: Split tooling into ~5 individual repositories (one per tool).
Pros:
- Clearer ownership and isolation per tool.
- Potentially cleaner dependency graphs.
Cons:
- Higher operational overhead (CI/CD, versioning, releases).
- Fragmented user experience (more dependencies to manage).
- Increased maintenance complexity.
🧠 Notes
- We are not sure this is the best solution. Therefore it's called "Attempt". If it turns out too complex, get in contact with @AlexanderLanin or @MaximilianSoerenPollak
- Merge as often as possible to avoid diverging from ongoing tool development
Metadata
Metadata
Assignees
Labels
No labels
Type
Projects
Status
Ready-for-implementation