BazelCon 2024

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.

In recent years, Scala has transformed from a language plagued by binary compatibility issues and complex tooling into one with rock-solid compatibility guarantees and an easiest entry point among JVM languages. VirtusLab has been at the forefront of this evolution, and now, enhancing Scala support in Bazel is our next milestone.

This talk will provide an overview of Scala's current state for Bazel users, highlight recent updates in rules_scala like cross-compilation, and outline our future plans. We aim to demonstrate why Scala is a strong choice for your current and future projects.

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.