Why did the Selenium project switch to Bazel? What things have gone well, and what are the rough edges? What contributions have the Selenium team made to the Bazel community? Come and find out!

Getting started with Bazel can be really hard. Getting started with Bazel in an existing repository with multiple different languages and a franken-build of its own can be harder. Doing that on a large and established OSS project can be harder still.

In this talk, I'll cover why the Selenium team moved to using Bazel, what challenges we ran into along the way, our struggles to move towards a completely hermetic build, and how we overcame (most) of these obstacles. In this talk, you'll find how we work with Java, JS, Python, Ruby, and .Net in the same project, with end-to-end tests using a range of browsers on a range of OSs. Not all our challenges were technical, some were social, and I'll be discussing those too.

On the course of this journey, members of the Selenium team have also contributed back to the Bazel community, and I'll be walking through some of these contributions, and how you could use them in your own projects.

Rust isn't supported by Bazel out of the box, but has thriving community support, making it a great example of the ecosystem's extensibility. Using a Rust project, Alexei will will demonstrate how the individual strengths of Bazel and Nix can be used to create even more reliable and reproducible build systems.

Bazel is a powerful and extensible build system, and Nix is a hermetic and transparent package manager. In this talk I will demonstrate how their individual strengths can be used in concert to create even more reliable and reproducible build systems; the kind we love most at Tweag.

We will be building a Rust project and compare the benefits of our approach to Cargo, Rust's canonical build and dependency management tool. Rust is not supported by Bazel out of the box, but has thriving community support, making it an interesting example of the ecosystem's extensibility.

In this talk, Google's Jason Dobies breaks down the results of the 2021 Developer Satisfaction Survey and provides some insight into the future of Bazel: What languages are most popular with our developers? What new features are they most interested in? How can we improve the user experience?

The tagline “{ Fast, Correct } — Choose two” is missing something: flexible. With dozens of rulesets spanning everything from shell scripting to programming languages, the possible use cases with Bazel are endless.

What languages are most popular with our developers? What new features are they most interested in? How can we improve the user experience? In this talk, Jason Dobies, a Developer Relations Engineer at Google, breaks down the results of the 2021 Developer Satisfaction Survey and provides some additional insight into the future of Bazel.

In this session, Zach Gray, Founder of Flare.Build will be joined by Mahdri Yechuri, Founder of Elotl, for an exploration of how they've used kubernetes to tame the complexity of managing distributed macOS build & test pipelines, with Bazel remote build infrastructure to scale performance and reduce costs.

The maintainers of bazelbuild/rulesnodejs have gone back to the drawing board. We studied RushJS and the package manager it uses, pnpm, and found this is a much better fit under Bazel. And we learned from our workaround for some node tools required running Bazel actions inside the output tree. We present aspectrulesjs, a new Bazel ruleset that replaces most of rulesnodejs with a radically simpler and more node-idiomatic way to fetch minimal npm packages and lay them out for runtime resolution.

Join us at the end of Day 1 of Bazel eXchange for this panel hosted by Andreas Herrmann from TWEAG.

Andreas will be joined by a selection of the days speakers for a virtual panel exploring a variety of topics that are front of mind for teams working within the Bazel build community.

In this talk, Zachi Nachson of WIX will share how his team migrated from Google RBE to BuildBuddy RBE. A serious engineering effort which was done with 0 downtime for our users.

Note: This session will be pre-recorded

Hang tight, more information will be coming soon!

Focus time is a precious commodity, especially for developers. What if you could reduce build and test cycles from hours to minutes, and get time back in your diary. Here’s how we did just that using Bazel and Clojure.

Where can we find more time to focus on the work that matters? At Griffin, this question is ingrained in our culture. The technology we use and how we use it plays a crucial role in helping us claw back precious time to focus on building an API-first bank. Bazel’s mechanics have helped us work more efficiently by pinpointing what we need to test and what we don’t need to test.

However, there were some challenges in using Bazel with our programming language, Clojure. I set my mind to extending Bazel so it could support our engineering needs, and as a result, we are now able to use these technologies together to reduce unnecessary distractions.

In this session, I will share my learnings with the Bazel community, including:

• How I got to grips with what makes Bazel tick.
• How I approached extending Bazel to work in harmony with Clojure.
• Tips and tricks developers need to do this themselves.
• Some sneaky shortcuts to success I learned along the way.

Running Bazel on a CI worker is easy, but making it perform well requires care. We'll discuss techniques like Auto-Scaling the agent pool elastically with demand, avoiding slow builds on cold agents, and other performance tricks. We also show how Buildkite's annotation feature allows you to show some Bazel results directly on Buildkite's UI rather than clicking out to a third-party results UI service.

The build discipline of the standard OCaml toolchain is complex and opaque. In this talk I will address some of the challenges I encountered developing the OBazl ruleset. I'll outline four major quirks in the build discipline and the methods developed to address them. Along the way I'll touch on most of the major features of the OBazl toolsuite.

I'll start with the concept of a module, which is central to both the language and the build discipline. A module is just a pairing of a structure (implementation) and a signature (interface). Conceptually, modules are relativey simple, but compiling modules is a surprisingly complicated affair.

Another major challenge for any OCaml build system is namespacing. The OCaml language is namespaced (in a sense I'll explain), but unlike many other languages with namespacing, OCaml does not define a mapping from namespaces to the file system. The compiler understands module "paths" like A.B.C, but it does not interpret such a segmented name as a file system path like A/B/C; rather, it will search for each segment as a file independent of directory. In other words, the module namespace is flat, which can lead to name collisions. To address this OCaml supports a mechanism called "module aliasing" that can be used to emulate filesystem-based namespacing. OBazl rules support two forms of namespacing, top-down (namespaces select their submodules) and bottom-up (modules elect namespace membership).

A third major challenge is handling compiler extensions. OCaml does not have a macro system, but it does support a small number of compiler extension points; these are usually referred to as "Pre-Processing eXtension", or PPXes. They require special support in a build system.

Fourth, most OCaml projects use the OPAM package manager. The OBazl toolsuite includes set of tools that support seamless integration of OPAM into the OBazl ecosystem.

Finally, I'll touch on some of the tooling I've developed to make it easier to use OBazl. Since OBazl, being a Bazel ruleset, requires that all dependencies of each build target be explicitly enumerated, generating and maintaining the BUILD.bazel files for any substantial project could involve a lot of tedious, error-prone work. Fortunately most of this can be automated, and I will give a brief overview of some tools addressing this issue.

In this session, Jimmy Judd will offer a brief history of working with Ticketmaster's custom VAX OS, how builds have evolved over 40 years and how he and his team have utilized Bazel to build a suite of highly related products including the VAX code.

Then we'll take a look at how the VAX code gets built using simple custom Bazel rules, and review the original code to understand how it actually works. By the end of this session, you'll be empowered to create your own simple custom build process using Bazel.

Join us as we wrap up Bazel eXchange with this panel hosted by Andreas Herrmann from TWEAG.

Andreas will be joined by a selection of the days speakers for a virtual panel exploring a variety of topics that are front of mind for teams working within the Bazel build community.