Bazel Community Day – San Francisco¶
On May 23, 2023, EngFlow teamed up with Snap to organize a Bazel Community Day for the Bay Area. Over 70 people attended the event, hosted at Snap's offices in beautiful San Francisco.
The meetup started and ended with informal discussion and snacks. The main event was a series of talks.
Migrating (parts of) an Embedded Linux Distribution to Bazel - Kyle Teske (Roku)¶
Roku is in the process of migrating their embedded operating system from a home-grown Make build system to Bazel. In this talk, Kyle spoke about the challenges they encountered. They were able to generate BUILD files for some libraries automatically, but Bazel has strict requirements on dependencies, and Roku found that they needed to fix cyclic dependencies and includes of private headers.
The migration is ongoing, but Roku expects to see significantly better reliability using Bazel, together with an improvement in build time.
Bazel UX: Flags & Console Output - Ulf Adams (EngFlow)¶
Ulf Adams, the co-founder and CTO of EngFlow and one of the original authors of Bazel, shared his thoughts on the Bazel command line user experience.
In the first half of the talk, Ulf recommended reorganizing Bazel's nearly 600 flags into six categories to aid understanding and to surface flags that are frequently used.
- Debug - flags that change how Bazel displays information about what is happening during a build.
- Input - flags that change how Bazel sees the work, affecting workspace layout, what is considered source, which targets are built, and which platforms they are built for.
- Rules - language-specific flags that change Bazel's behavior for built-in rules.
- Migration - flags that support the controlled rollout of semantic changes to Bazel and its rules including changes to Starlark, the rule API, and rule semantics.
- Strategy - flag that change how Bazel executes actions including caching, sandboxing, remote execution, and test sharding.
- Meta - low-level flags that affect how Bazel works internally, mostly dealing with in-memory caches and out-of-memory errors.
In the second half of the talk, Ulf spoke about Bazel's terminal output during a build and suggested ways it could more clearly surface errors and other relevant information to users. There are many different personas and use cases for terminal output though. Ulf encouraged the audience to think about the output that's important to them and work in the Bazel open source project if it interests them.
Migrating away from rules_docker to rules_oci - Alex Eagle (Aspect)¶
Alex Eagle, the founder and co-CEO of Aspect and the maintainer of rules_oci and many other rule sets, spoke about building container images with Bazel using rules_oci. At the beginning of the talk, Alex tagged the v1.0.0 release!
rules_docker has been maintained by Google, but it has been difficult for Google engineers and for the community to keep it up to date. It relies on checked-in binaries that aren't open source, and many language-specific rules.
The new rules_oci is smaller and simpler, relying on pkg_tar for building layers and on capable image manipulation tools like Crane.
Taming node_modules in RBE: Airbnb's Journey - Sharmila Jesupaul (Airbnb)¶
Sharmila Jesupaul, a software engineer at Airbnb, spoke about building and testing TypeScript code at scale using Bazel's remote execution. The team is in the process of optimizing their CI system to test a large volume of front-end code in a 15 minute time budget. Sharmila shared several techniques they used to make large actions run faster.
Packaging dependencies as tarballs and pruning unneeded files sped up type checking actions enormously from 35 minutes to 12 minutes.
Sharmila and her team found that actions still spent a significant amount of time extracting tarballs of node_modules directories. They compromised on hermeticity for the sake of speed by caching extracted directories on each remote execution worker outside the execution root. This allowed remote actions to skip extraction when an earlier action had extracted the same tarball. This sped up unit testing from 30 minutes to 22 minutes. This approach still had some drawbacks: workers' caches are lost when they are scaled down, and changes to tarballs invalidate the cache.
The last technique Sharmila shared was packaging a read-only tarball cache in the Docker image used by remote workers. This allowed even newly started worker machines to hit the cache, speeding up test times to 16 minutes.
Supporting multiple Spark versions with Bazel - Ted Kaplan (Roku)¶
Ted Kaplan, a software engineer at Roku, described how his team supports multiple versions of Scala Spark in their monorepo.
Spark depends on a large number of Java libraries like Jackson and Guava. A conflict occurs when your application depends on a new version of one of those libraries but Spark depends on an old version.
Maven solves this problem with shading: conflicting classes are relocated to a different package so they appear to be different. Bazel uses a tool called JarJar Links to shade Java binaries, but this is slow for large Java binaries and is prone to cache misses when anything changes.
Ted explained how Roku solved this, using a Bazel aspect to apply shading to individual targets. They also use build settings and transitions to allow libraries to depend on Spark without explicitly mentioning a version, allowing the version to be set for the whole application at build time.
No French Required or How to Build OCaml code with Bazel - Tim Jäger (SandboxAQ)¶
Tim Jäger, a software engineer at SandboxAQ, spoke about the upcoming risks around quantum computers. Shor's algorithm can break RSA encryption and Diffie-Hellman key exchange, both of which are widely used. Quantum computers capable of executing Shor's algorithm at scale don't exist yet, but likely will in 10–30 years, and large adversaries are already capturing and storing encrypted traffic in order to decrypt it later. Quantum-resistant algorithms already exist, but migration to them is difficult.
SandboxAQ acquired a company called Cryptosense to help with this migration. Cryptosense primarily uses OCaml the "national programming language of France", and SandboxAQ needed to build their code with Bazel.
OCaml developers primarily use the Dune build system, developed at Jane Street. Tim built an OCaml rule set for Bazel, supporting libraries, binaries, tests, packaging, type checking. They even have an ocaml_repl rule allowing developers to start an interactive prompt in any package. Their rules can also import OCaml dependencies into WORKSPACE.bazel files.
We enjoyed meeting everyone and hearing fascinating talks on a variety of subjects. Thanks again to Snap for hosting us at their San Francisco office! We look forward to seeing everyone at the next community day!
Bringing Bazel Community Day to You¶
Fill in this survey if you’d like to join us at a future event and be informed about training and meetup opportunities.
Follow us on LinkedIn and X (Twitter), and join our newsletter to be the first to know about upcoming community days and other events!