How Uber Manages Go Dependencies with Bzlmod
summary
Uber migrates a thousand-plus direct Go dependencies from go_repository rules into Bzlmod, using go.mod/go.sum as the source of truth and Gazelle to generate repos (currently via gazelle update repos and use_repo entries). Built a proxy-caching registry (Artifactory/BCR proxy) to avoid BCR outages, and automated tidy/cleanup steps planned for Bazel 7.1. Module.bazel grows to ~2,000 lines, overrides balloon to 100–200 entries, ownership mapped to directories with metadata reviewers — overrides and central module.bazel management are the remaining pain points.
AI-written summary · about
chapters (11)
- 0:00Uber's Go dependency management
- 1:26Go repo rules pains in Bzlmod
- 2:53Bzlmod simplifies Go deps
- 3:55go.mod as Bzlmod source
- 4:58Bzlmod future improvements
- 5:43Migration strategy for Bzlmod
- 7:05Bzlmod internal registry
- 8:12Repository rules in module.bzl
- 9:17Dependency ownership in Bzlmod
- 10:22Overrides challenges in Bzlmod
- 11:27Bzlmod future and contributions
related talks
09mBazel: {Fast, Correct, Seamless}: Choose 3
48mMobile Developer Productivity at Scale
11mPerformant Bazel Builds for Web Monorepos at Scale
31mBazel: Do We Really Need Another Build Tool?
07mOptimizing Gazelle for Scale and Performance in Uber's Monorepo
30mGenerating BUILD Files
35mTools of the Trade
11mLightning Talk – Why Not To Have Bazel Dependencies