GO — Healthy across the board

• Last commit today
• 34+ active contributors
• Distributed ownership (top contributor 15% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

Bazel is a fast, scalable build system that handles compilation, testing, and dependency management across Java, C++, Python, Go, Android, iOS and 10+ other languages. It uses a hermetic, content-addressable cache and parallel execution to rebuild only what changed, enabling monorepo builds at massive scale (Google, Twitter, Stripe use it for millions of LOC). Layered architecture: Java core engine in src/main/java/ implements build graph analysis, caching, and execution; Starlark rule system in tools/starlark/ defines user-facing DSL; CLI in src/main/java/com/google/devtools/build/lib/bazel/; language-specific rules live in bazel-skylib/ and external rules repos. .bazelci/ drives multi-platform CI; compile.sh bootstraps from source.

Build engineers and infrastructure teams at large organizations managing polyglot monorepos; language rule authors building Starlark-based toolchain integrations; developers on projects with complex cross-language dependencies needing reproducible, distributed builds.

Production-ready and actively maintained by Google-backed maintainers. The repo shows 45MB Java, comprehensive CI/CD via .bazelci/ (presubmit/postsubmit/binary builds), deep test coverage, and regular releases tracked in .bazelversion. Multiple GitHub workflows and BazelCI integration indicate mature release and validation processes.

Large monorepo (180MB+ across all languages) with complex build semantics means changes ripple far. The project has significant breaking-change risk (see .github/ISSUE_TEMPLATE/incompatible_change.yml); dependency on Starlark interpreter adds language-specific bugs. Single maintainer points exist for language rules; security contact is security@bazel.build with 90-day disclosure SLA, suggesting active threat model.

Active development on build-system scalability and language rule expansion. .github/workflows/ shows ongoing cherry-picker automation, SSL certificate monitoring, community labeling (cherry_pick_request.yml suggests hotfix culture), and stale-issue management. MODULE.bazel indicates module system work (Bazel's dependency management evolution).

git clone https://github.com/bazelbuild/bazel.git && cd bazel && bash compile.sh (bootstraps Bazel from source; see compile.sh and .bazelversion for version constraints). Alternatively, install pre-built binary from https://bazel.build/install and run 'bazel version'.

Daily commands: bazel build //src/... (builds Bazel itself) or bazel test //src/... (runs unit tests). For development: bazel run //src/main/java/com/google/devtools/build/lib/bazel:bazel -- --version. See .bazelrc for default configs (e.g., startup flags, test args).

• README.md — Core project overview explaining Bazel's value proposition, supported languages, and getting started resources that every contributor must understand.
• CONTRIBUTING.md — Contribution guidelines and development workflow that all contributors must follow before submitting changes.
• BUILD — Root-level Bazel build file defining the project's main build targets and dependencies for the entire codebase.
• MODULE.bazel — Bazel module definition using bzlmod system for dependency management and external repository configuration.
• .bazelrc — Default Bazel configuration file with build flags and settings that affect how Bazel builds itself.
• .bazelci/presubmit.yml — CI/CD pipeline configuration that runs automated tests and builds on all pull requests before merge.
• CODEOWNERS — File ownership mapping that defines code review requirements and team responsibilities across the repository.

Add a new language rule support

1. Create a new rule definition file in an appropriate subdirectory under the build system (BUILD)
2. Add the rule module to MODULE.bazel as a new dependency or internal target (MODULE.bazel)
3. Document the new rule with usage examples in the docs/basics or docs/advanced directory (docs/basics/index.mdx)
4. Add CI/CD test coverage in the appropriate presubmit configuration (.bazelci/presubmit.yml)

Report or fix a security vulnerability

1. Review the security reporting guidelines before disclosing (SECURITY.md)
2. Create a private security advisory through GitHub's security tab (.github/ISSUE_TEMPLATE/bug_report.yml)
3. Submit a pull request with the fix referencing the security advisory (CONTRIBUTING.md)
4. Update CHANGELOG.md to document the security fix in the release notes (CHANGELOG.md)

Contribute a documentation update

1. Review the documentation structure and style guide (.gemini/styleguide.md)
2. Edit or create an .mdx file in the appropriate docs subdirectory (docs/advanced/performance/build-performance-breakdown.mdx)
3. Ensure the documentation is included in the build (docs/BUILD.bazel)
4. Submit a PR following contribution guidelines (CONTRIBUTING.md)

Release a new version of Bazel

1. Update version reference if needed (.bazelversion)
2. Document changes in the changelog (CHANGELOG.md)
3. Trigger the release workflow through GitHub Actions (.github/workflows/release-helper.yml)
4. Verify binary distributions are built correctly (.bazelci/build_bazel_binaries.yml)

• Bazel (self-hosting) — The build system uses itself to build itself, demonstrating correctness and enabling dogfooding of new features before release
• Starlark (Python-like DSL) — Extensible language for rules and build definitions that balances developer ergonomics with reproducibility and security
• GitHub Actions + BazelCI — Multi-platform CI/CD system supporting Windows, macOS, and Linux with configurable presubmit and postsubmit pipelines
• Bzlmod (Module system) — Dependency management system that enables reproducible builds and clear module boundaries across the monorepo
• MDX documentation — React-compatible markdown format allowing interactive documentation while maintaining static site generation capabilities

• Monolithic repository structure for Bazel itself

  • Why: Enables tight integration testing, unified versioning, and consistent development workflow
  • Consequence: Requires sophisticated CI/CD orchestration and careful change management to avoid breaking the bootstrap build

• Support multiple languages and platforms in a single tool

  • Why: Provides unified build experience and reduces tool fragmentation for polyglot organizations
  • Consequence: Increases complexity of rule design, testing matrix, and documentation scope

• Starlark instead of a general-purpose language

  • Why: Restricts mutability and side effects to ensure reproducibility and deterministic builds
  • Consequence: Steeper learning curve for developers familiar with imperative languages

• Distributed cache and remote execution as optional features

  • Why: Allows Bazel to work offline and on resource-constrained systems while providing enterprise scalability
  • Consequence: Users must manually configure distributed infrastructure for large-scale deployments

• Does not manage runtime application dependencies—focuses on build-time artifacts only
• Does not provide an IDE or text editor plugin—integrates with existing development environments
• Does not enforce specific coding standards or linting—delegates to language-specific rules and tools
• Does not support non-hermetic builds—requires explicit dependency declarations and environment isolation

Bootstrap chicken-egg problem: compile.sh requires existing Java toolchain (JDK 11+) to build Bazel itself; can't use Bazel to bootstrap Bazel initially. .bazelversion pins exact version for reproducibility; mismatched versions cause cryptic errors. Starlark has Python-like semantics but NO mutable state (immutability is enforced); newcomers struggle with this. Remote caching credentials (gRPC auth) must be configured in .bazelrc for distributed builds; missing config silently falls back to local. Module system (MODULE.bazel) is young; legacy WORKSPACE-based projects have different semantics.

• Content-Addressable Build Cache — Bazel's core innovation: action outputs are identified by input hash, not timestamp, enabling perfect incrementality and cross-machine cache hits; essential to understand for cache strategy and distributed builds
• Hermetic Builds — Bazel enforces that builds depend only on declared inputs (no implicit /usr/lib or $PATH dependencies); violations break hermeticity and cause cache misses; critical for reproducibility
• Directed Acyclic Graph (DAG) Analysis — Bazel builds a complete dependency DAG before execution, enabling parallel builds and fine-grained incremental rebuilds; understanding traversal order and cutting-edge (targets with no dependents) is key to optimization
• Starlark (Bazel's Domain-Specific Language) — User-facing rule definition language (Python-like but immutable); most customization happens here; key differences from Python (no loops, no state) trip up newcomers
• Bazel Aspects — Mechanism to inject analysis logic across transitive dependencies without modifying rules (e.g., collecting metadata); used for linting, code-gen, profiling; powerful but non-obvious
• Remote Execution (BuildFarm / Execution Service) — Bazel can offload action execution to gRPC-based remote servers; enables CI/CD scale but requires understanding action sandboxing, input/output spec, and cache invalidation
• Toolchain Resolution — Bazel's mechanism to select compiler/linker/formatter based on platform and constraints; rules query toolchains at analysis time; central to cross-compilation and polyglot builds

• bazelbuild/bazel-skylib — Shared Starlark standard library and utility rules used by most Bazel projects; extends base rule set
• bazelbuild/rules_java — Official Java rules reference implementation; demonstrates how language-specific rules integrate with core Bazel
• bazelbuild/rules_cc — Official C/C++ rules; required for C++ builds, shows integration with Clang/GCC toolchains
• grpc/grpc — Bazel uses gRPC for remote execution protocols; understanding RPC serialization helps with distributed build debugging
• bazelbuild/buildtools — Companion repo with Bazel linting (buildifier), formatting, and query tools; essential for large-scale repo maintenance

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive SSL domain validation tests for .github/config/ssl_domains.yaml

The repo has SSL monitoring infrastructure (.github/scripts/check_ssl.py and .github/workflows/ssl-monitor.yml) but lacks explicit unit tests validating the SSL domain configuration format, certificate pinning logic, and domain list parsing. This is critical for security-related infrastructure.

• [ ] Create src/test/java/com/google/devtools/build/lib/ssl/ directory (or equivalent test location)
• [ ] Write tests for .github/scripts/check_ssl.py validation logic covering: domain format validation, certificate chain verification, expiry date parsing
• [ ] Add test cases for .github/config/ssl_domains.yaml loading and parsing (YAML format, required fields)
• [ ] Integrate tests into appropriate Bazel test targets and CI pipeline

Create missing unit tests for .github/scripts/community_review_labeler.sh

The community review labeler script (.github/scripts/community_review_labeler.sh) lacks corresponding test coverage. Given it's a security-related automation task that applies labels based on contributor status, it needs comprehensive tests to prevent regressions.

• [ ] Create .github/scripts/tests/community_review_labeler_test.sh or equivalent test suite
• [ ] Write test cases for: trusted contributor detection (using .github/config/trusted_contributors.yaml), label application logic, edge cases (new contributors, bots, etc.)
• [ ] Mock GitHub API responses for PR/issue metadata
• [ ] Document test execution in CONTRIBUTING.md with specific test invocation instructions

Add pre-commit and pre-push Git hook documentation and templates to .devcontainer/

While .devcontainer/devcontainer.json exists for dev environment setup, there's no documented Git hooks (pre-commit, pre-push) to help contributors catch issues early. Given the large scale of the Bazel project and complexity of CI (presubmit.yml, postsubmit.yml), hooks would save CI cycles and contributor time.

• [ ] Create .devcontainer/hooks/ directory with pre-commit and pre-push hook templates
• [ ] Document hooks in CONTRIBUTING.md with setup instructions (git config core.hooksPath .devcontainer/hooks/)
• [ ] Implement pre-commit hook: validate BUILD/MODULE.bazel syntax, check .bazelrc formatting, lint shell scripts in .github/scripts/
• [ ] Implement pre-push hook: run basic buildifier checks and lint YAML files (.bazelci/.yml, .github/workflows/.yml)

• Add missing BUILD file documentation in bazel/tools/starlark/: most .bazel stdlib files lack docstrings explaining rule signatures (good for learning rule system and writing first PRs without core engine risk).
• Expand .github/scripts/check_ssl.py test coverage: currently no unit tests for SSL domain validation logic; add tests for wildcard certificate chains and cipher suite checks (low-risk, improves CI robustness).
• Document MODULE.bazel migration guide in CONTRIBUTING.md: repo uses new Bzlmod system but lacks onboarding for contributors updating dependencies; add examples of bazel_dep() vs legacy http_archive() (documentation-only, high impact for new contributors).

Bazel's security posture is generally strong with established vulnerability disclosure procedures, integrated Dependabot configuration for dependency management, and organized GitHub security workflows. Main areas for improvement include using full URLs instead of shortened links for security reporting, comprehensive review of CI/CD workflow configurations to ensure least-privilege principles, and verification that automated dependency scanning is actively enforced. No critical vulnerabilities were identified in the visible file structure, but deeper code analysis would be required to assess runtime security, injection vectors, and secret management practices.

• Medium · Insecure Vulnerability Disclosure URL — SECURITY.md. The SECURITY.md file references 'https://g.co/vulnz' for vulnerability reporting. Google short URLs (g.co) can be difficult to verify and may pose phishing risks. While this is a legitimate Google service, shortened URLs make it harder for security researchers to verify the authenticity of the endpoint. Fix: Consider using the full, permanent URL instead of a shortened URL for vulnerability disclosure. Provide both the short URL and the full URL for transparency and security verification.
• Low · Dependency Management Visibility — MODULE.bazel.lock and root directory. The repository contains a 'MODULE.bazel.lock' file, but no conventional package dependency manifest was provided in the analysis (e.g., package-lock.json, requirements.txt, pom.xml, go.sum). This makes it difficult to assess third-party dependency vulnerabilities. Fix: Ensure dependency scanning tools are configured in CI/CD pipelines. Consider integrating automated dependency vulnerability scanning (e.g., Dependabot, which is already present in .github/dependabot.yml) with regular security updates.
• Low · GitHub Actions Workflow Security — .github/workflows/. Multiple GitHub Actions workflows are present (.github/workflows/), but without inspection of their content, there's a potential for privilege escalation or credential exposure if workflows are not properly configured with least-privilege principles. Fix: Review all GitHub Actions workflows to ensure: (1) GITHUB_TOKEN permissions are minimized, (2) no hardcoded credentials, (3) third-party actions are pinned to specific commits, and (4) secrets are never logged or exposed in build artifacts.
• Low · Configuration Files Not Encrypted — .github/config/ssl_domains.yaml, .github/config/trusted_contributors.yaml. The .github/config/ssl_domains.yaml and trusted_contributors.yaml files could potentially contain sensitive configuration. While likely safe, any sensitive data in config files should be encrypted or use secrets management. Fix: Use GitHub Secrets for any sensitive configuration data. Keep non-sensitive configuration in version-controlled files, but review them for accidental credential leakage.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/bazelbuild/bazel shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live bazelbuild/bazel repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/bazelbuild/bazel.

What it runs against: a local clone of bazelbuild/bazel — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in bazelbuild/bazel | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of bazelbuild/bazel. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/bazelbuild/bazel.git
#   cd bazel
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of bazelbuild/bazel and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "bazelbuild/bazel(\\.git)?\\b" \\
  && ok "origin remote is bazelbuild/bazel" \\
  || miss "origin remote is not bazelbuild/bazel (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"
test -f "BUILD" \\
  && ok "BUILD" \\
  || miss "missing critical file: BUILD"
test -f "MODULE.bazel" \\
  && ok "MODULE.bazel" \\
  || miss "missing critical file: MODULE.bazel"
test -f ".bazelrc" \\
  && ok ".bazelrc" \\
  || miss "missing critical file: .bazelrc"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/bazelbuild/bazel"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.