BazelCon 2024

Dive into the new mechanism we recently added to rules_cc through which we define C++ toolchains. Our new mechanism to do it is simpler, safer, explicit, and modular, and removes many of the confusing concepts such as compile_files.

Symbolic macros are well-structured macros with rule-like capabilities, like typed, well-documented attributes, good behavior with labels and selects(), and declared dependencies. Learn more about the structure and benefits of symbolic macros and how to use them in your code base. In addition, learn about upcoming work on rule finalizers, a special symbolic macro which - regardless of its lexical position in a BUILD file - is evaluated in the final stage of loading a package, after all non-finalizer targets have been defined.

At Aurora, many of the tests that our developers rely on are computationally expensive simulations that rely on specialized and expensive GPU hardware. We use tooling similar to bazel-diff and target-determinator to figure out what targets have changed between two git revisions, then run specific tests based on those targets. This method scaled well until our build graph reached a certain size. Changing common code triggered a larger and larger number of low-signal tests. This slowed down developer velocity due to having to wait on more tests and being more likely to get hit by a flaky test failure. We updated Aurora's in-house changed target detection tool to emit build graph distance metrics that measure the distance between a changed target and a directly modified file. This distance metric allows us to confidently skip running some tests to avoid the issues described above. In this session, I will discuss how we compute build graph distance metrics and the ways that we use them to power workflows that increase developer velocity and improve mainline stability in a domain rich with expensive-to-run tests.

A talk on why Nix and Bazel does not pair with each other well, recommending to use Bazel and bzlmod instead of Nix. Specifically, Nix is a package manager that is often misintegrated into Bazel. It is incompatible with the Bazel ecosystem in that * Nix artifacts are not relocatable, breaking Bazel remote execution when Nix outputs are in the build graph * Nix binaries are incompatible with FHS and rulesets that expect FHS because binaries are located in Nix store * Users who are familiar with Bazel are (usually) not familiar with Nix. Our engineers are often unable to self-serve patches to Nix packages, and they are also unable to use the testing framework provided by Bazel (which are familiar to most engineers) to validate their patches because of the steep learning curves * At monorepo our size, it is not rare to see Nix expressions that produces several thousand derivations that each reference large sets of build inputs. Expression evaluations are often so slow that nix-builds are in the critical path during analysis phase, even though outputs are already in the Nix cache. Nix flakes can help but it has an awkward git integration which does not work very well in large monorepos

Tools for formatting code and performing static analysis are available in some of Bazel's language rules, but their approaches differ. This means each language has to be setup separately, and product engineers may have to learn multiple workflows across the full stack. rules_lint provides a consistent abstraction for plugging in language-specific tools, and avoids requiring changes either in language rulesets, or in user's BUILD files. In your repository you setup a single "format" workflow, and a single "linting" workflow. This talk explains why these two workflows are distinct. We'll explain how to integrate new tools into rules_lint, options for installing it into your repository, and show some nice ways that results can be integrated into developer workflows.

At MongoDB we do not have one central codebase or only one language. As we continue to scale this fractured ecosystem is harder to maintain so we needed to migrate these disparate repos to a shared development platform. Our first step in that journey is migrating large repos to be built with Bazel so that the build team can make a feature once and it can benefit all of our developers. MongoDB’s approach to doing this is novel because we were able to de-risk these projects by supporting significant interoperability during migration. The downside, which is what most of this talk will be about, is dealing with the large amount of configuration in the build system. For example, the MongoDB C++ codebase had ~112 configuration options and remote compilation (not with RBE) before this process began and before converting even a single target we needed to support many of these configuration options and two remote execution environments. We are going to speak about the tools we used and created for these transitions, techniques we used for maintaining our hybrid build system, and how you too can switch to Bazel gradually and gently with the enthusiastic support of your organization.

Are lurking problems in your Bazel builds costing you more than you think? What if hidden patterns in your build data could reveal the most impactful problems to fix? Develocity, Gradle's cross-build observability platform, helps you uncover those insights and take appropriate action. In this lightning talk, we'll explore how Develocity's unique multi-build analysis can help you: * Identify and prioritize systemic build failures with the highest impact on your team’s productivity * Pinpoint flaky tests that slow you down * Gain deeper insights into your Bazel builds’ health for faster troubleshooting and better decision-making Let your build data become the key to a more efficient and productive development workflow.

Large monolithic targets are a difficult bottleneck to fix when creating a wide and flat build graph. Learn how Tinder uses key Bazel features such as Aspects alongside Swift’s IndexStore technology to visualize large targets, determine file extraction priority and automate the work of decoupling a subset of files from a target. This talk will provide a framework for decomposition with any project that uses Bazel, which can be used to finally swipe left on those monolithic targets.

There are more than one solution for generating a compilation database for Bazel today: Aspects, Action Query, Extra Actions etc. In this talk, I will talk about the pros and cons of each approach, and what we ended up with.