BazelCon 2024

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.