The Maintainer
Dependencies, configuration, and project setup
Turn Bazel into shared project infrastructure: manage external dependencies, stabilize invocation policy, express supported platforms, keep generated structure honest, and make local and CI workflows repeatable.
At Level 3, individual Bazel choices become repository policy. A maintainer makes those choices repeatable for other people: which dependencies enter, which flags define normal invocations, which platforms are supported, which files are generated, and which workflows belong outside the build graph.
Put Each Decision In Its Owning Layer
The first responsibility is the project boundary. 3.1 Dependency Management
shows how external code becomes named repositories through Bzlmod, module
extensions, repository mapping, registries, lockfiles, and legacy WORKSPACE
coexistence. 3.2 Project Configuration then turns individual command lines
into shared policy: .bazelrc, flags, stamping, hermeticity defaults, ignored
directories, wrappers, and flag lifecycle.
The second responsibility is controlled variation. 3.3 Configurable Builds & Platform Basics
is about expressing supported build variants without relying on ambient host
state. select(), constraints, platforms, target compatibility, and
--platforms all become one vocabulary for saying what this repository can
build and under which conditions.
The third responsibility is keeping the declared world honest. 3.4 Code Generation & BUILD Maintenance
separates build outputs from source-tree maintenance: genrule belongs inside
the graph, while Gazelle, Buildozer, formatters, linters, and unused-deps tools
usually prepare or repair the checkout around it.
The last responsibility is making the system livable. 3.5 Developer Experience & Local Tooling connects Bazel to IDEs, local tools, inner loops, and CLI extensions. 3.6 CI Basics takes the same contract to short-lived CI machines. 3.7 Workflow Orchestration (Outside the Graph) protects Bazel's boundary when a useful workflow needs source rewrites, publishing, coverage reporting, or cross-revision coordination.
Start With Shared Policy
For a normal modern repo, start with 3.1 Dependency Management and 3.2 Project Configuration. They define what code enters the workspace and how a command becomes project-approved build behavior. Add the other sections when the pressure appears: platform branches, BUILD drift, local tooling pain, CI setup, or workflows that do not fit cleanly inside one target graph.
Maintaining Bazel means governing dependencies, invocation defaults, supported platforms, generated metadata, and local or CI workflows in the layers that own their state. Source-changing and publishing side effects remain explicit workflows outside Bazel actions.
Next: design reusable Starlark and rule contracts in 4.1 Macro Design & Rule-Authoring Starlark.
