BazelCon 2024

Enticed by advanced features, several software teams have migrated their build systems to a modern generation of build technologies, such as Bazel. However, not all migrations lead to perceived improvements, ultimately culminating in abandonment of the build technology. In this talk, we will present the results of our recent empirical study of 542 open-source projects that adopt Bazel. We observed that (1) 61 projects (11.2%) have abandoned Bazel; and (2) abandonment tends to occur after investing in Bazel for a substantial amount of time (a median of 638 days). Thematic analysis reveals seven recurring reasons for abandonment, such as technical challenges, lack of platform integration, team coordination issues, and upstream trends. After abandoning Bazel, the studied projects have adopted a broad set of alternatives, spanning from language-specific tools like Go Build, to more traditional build technologies like CMake and even pure Make.

Discussing the last year of rules_swift, rules_apple, rules_xcodeproj, and rules_swift_package_manager updates, where we are going with the rulesets. Lots of time at the end will be open Q&A.

Bazel is typically described as a build system meant for large-scale systems. It's also described as a build system meant for teams with dedicated help to Bazel. But...what if you have neither? What if you are a small-scale start-up? Start-ups, by their nature, rarely have a spare headcount to devote to a build systems engineer. Their codebases are also usually pretty small. Why on Earth would you use Bazel in that context? Ergatta *is* using Bazel in that context. Ergatta has [note: I can put the real amount in here if this is accepted] LOC. Ergatta does not have the headcount to devote an engineer to Bazel. How does it work? How does a start-up with a 10-person engineering team work with a system that notoriously requires so much maintenance? In this talk, I'll talk about why we would ever entertain such a notion, what makes Bazel work for us, and how we remain productive in these times.

At Spotify, we migrated the Android Music app, consisting of 5 million lines of Kotlin, Java and C++ code, from Gradle to Bazel. This talk covers the how we did it, the challenges we faced and how we overcame them. We'll go into how we used a hybrid build to migrate the codebase iteratively, the various patches and performance improvements we made to Bazel and the features we implemented to release the app to end users.

Many at this conference are familiar with Remote Caching and Remote Execution. Over at BuildBuddy, we’re excited to introduce Remote Bazel - running the Bazel client server and command remotely as well, making your builds even faster and more correct. Even if your builds are triggered by ephemeral CI runners, Remote Bazel will guarantee your builds always run with a warm analysis and repository cache, and remove the need to pull images, install dependencies, and clone git repos on each run. Running builds in the same datacenter as the remote cache and executors also reduces network bottlenecks and egress costs. Even if your company’s developers use machines with different operating systems or versions of tools or don’t even have Bazel installed, Remote Bazel will guarantee that important builds are run in the exact same environment every time. This talk will provide a quick overview of how we built this and the many applications we’re excited about - from speeding up CI to augmenting our UI to improving the daily developer experience via the CLI.

This session will focus on the powerful and often underutilized querying capabilities of Bazel. While many users know the basics of query, aquery, and cquery, less of them fully leverage their potential. This talk will introduce advanced techniques and practical use cases that can significantly enhance build debugging and tooling development process. Attendees will discover how advanced query features can improve their workflows and possibly inspire the creation of custom tools. Both advanced users and beginners will learn something new from this talk.

Governments and NGOs are in the process of regulating the software pipeline. We are increasingly called on to produce SLSA compliance documents such as a Software Bill of Materials (SBOM).  Requirements and tooling in this space are evolving, as more customers need to understand their entire software supply chain, from the OS up to the bits delivered to users. This forum will explore the gap between what we can deliver with Bazel today and the community's anticipated future needs.  

Please help seed this discussion by contributing to the document here.

rules_nixpkgs brings the power of Nix to Bazel dependencies. It provides access to the large nixpkgs package repository and benefits from hermeticity and declarative configurations that are dear to both the Bazel and Nix communities. But despite all the benefits, it still comes with one major downside. It makes remote execution of Bazel actions next to impossible but for some restricted use cases. In short, rules_nixpkgs and remote execution are like oil and vinegar. It takes effort to blend them into a tasty vinaigrette, but once you do, you'll never look back to your plain old builds. In this talk, we will introduce the challenges posed by this integration. Various solutions have been proposed over the years. We will explain how we chose one by looking at how these solutions propagate the necessary information across their components. We will then delve into the specifics of our design, explore technical aspects of our deployment, and discuss issues and benefits observed in practice. The last part will focus on performance metrics. We will share our understanding of the impact this change had on our infrastructure and, most importantly, on developers.

Discuss topics surrounding Bzlmod, Bazel's new external dependency management system.

Toolchains and platforms are there to last, and yet my experience shows that they can be challenging for newcomers, and can still surprise experienced Bazelistas. Some time ago, a debug session led me to read the actual source code, and I ended up refactoring the messages dumped by `--toolchain_resolution_debug` in the hope to make them more intuitive and self-explanatory. This session will present the new message format and build upon its structure to explain the algorithm that drives platforms and toolchains selection. Attendees will build a clear mental model of that core part of Bazel. Additionally, the presentation will insist on the importance of crafting self-explanatory messages, along with the tradeoffs involved. Debugging toolchain issues is now easier than ever, and a little bit funny.

In highly regulated industries such as automotive, aviation, and medical, test artifacts are often essential for further reporting. Automotive SPICE (ASPICE) or AUTOSAR from the automotive field requires detailed, reproducible reporting on executed tests. Companies such as BMW or NVIDIA use Bazel to build their software. However, Bazel does not cache test execution output, but only that a test was executed. To address this, some companies have resorted to forking Bazel and implementing this feature on their own which causes maintenance overhead and impedes collaborative Bazel improvements. Our proposed solution is to treat the test binary as a tool and run it as part of the Bazel build phase. This way, we can depend on the test output for further processing such as skipping integration tests if unit tests fail, collecting output artifacts such as human-readable test reports and machine-readable coverage reports, as well as making coverage collection depend on test outputs. Thanks to Bazel’s caching, the test is not executed again in the test phase which makes this solution an acceptable tradeoff.