Skip to content

2025

EngFlow at BazelCon 2025

The EngFlow team recently wrapped up a successful BazelCon 2025, which marked a significant milestone: the 10th anniversary of Bazel! Seeing the energy and innovation at the conference was especially meaningful for us, as several of us have been involved in BazelCon since its inception, both as organizers and attendees. We're reflecting on the immense growth the community has achieved in the last decade and how it spearheads developer productivity across the world.

EngFlow was a platinum sponsor of the main conference, facilitated several workshops on Training Day, and co-hosted a fun Game Night with JetBrains and VirtusLab. We loved seeing and hearing from many of our customers in-person at BazelCon, as Happy Customers are at the heart of what we do!

This blog brings you highlights from the conference and satellite events.

The EngFlow team at BazelCon 2025

The EngFlow team at BazelCon 2025
  • in engflow
  • 3 min read

Enhanced Invocation-level Insights for Bazel Builds

In recent weeks, we’ve added several powerful enhancements to EngFlow’s Build and Test UI to bring you deeper invocation-level insights. These improvements make it easier than ever to identify and diagnose slow or cache-inefficient actions, enabling you to optimize faster and get the most out of your Remote Execution setup.

  • in bazel
  • 9 min read

Writing Bazel Rules: Module Extensions

This article originally appeared on jayconrod.com as part of the Writing Bazel Rules series.

It's been almost six years since the previous entry in this series was originally published, and there are many new topics to discuss!

The biggest change in the last few years was the introduction of Bazel modules (also known as Bzlmod) and the deprecation of WORKSPACE mode. I've updated all the previous articles to be compatible with Bazel modules, but today we'll explore newly introduced functionality: how to write a module extension, and why you'd want to do so.

Migrating to Bazel Modules (a.k.a. Bzlmod) - Maintaining Compatibility, Part 4

This "Maintaining Compatibility" trilogy began by describing how to, well, maintain compatibility with Bzlmod builds, legacy WORKSPACE builds, and a range of dependency versions. However, this was only half the story. Automated testing is essential for validating our compatibility assertions, not lying to ourselves and our users, and preventing the undoing of our hard work.

The previous post described how to write and run tests that enable switching between Bazel versions and the Bzlmod and legacy WORKSPACE build modes. Those tests use the latest versions of our non-Bazel dependencies to ensure forward compatibility.

This fourth and final part of our trilogy describes how to write tests to validate backwards compatibility with combinations of older dependency versions. We'll build on the techniques from the previous post, while learning what makes these backwards compatibility tests substantially different from other tests in the suite.

Migrating to Bazel Modules (a.k.a. Bzlmod) - Maintaining Compatibility, Part 3

After the massive, yet warranted digression regarding updating legacy WORKSPACE macros that use Label, we now resume our regularly scheduled programming.

We've covered techniques for ensuring that your project remains compatible with different Bazel versions, both Bzlmod and legacy WORKSPACE builds, and older dependency versions. However, we shouldn't make any promises until we've validated that these properties actually hold, preferably via automated testing and continuous integration.

This third post in our four part trilogy covers writing Bazel tests that allow for flexibly switching between various Bazel configurations. We'll consider advice on how to run the tests locally while developing and how to run them in continuous integration.

Migrating to Bazel Modules (a.k.a. Bzlmod) - Maintaining Compatibility, Part 2

In the previous post, we reviewed guidelines for maintaining compatibility with both Bzlmod and legacy WORKSPACE builds, and older and newer dependency versions. I promised that in this post and the next, we'd discuss testing approaches to help ensure that this remains the case.

However, a discussion in the Bazel Slack workspace has revealed a Bzlmod and legacy WORKSPACE compatibilty issue I'd missed in the previous post. So in this post, I'll discuss what to do with the class of legacy WORKSPACE configuration macros that use Label with computed repository names.

As we'll see, this one issue alone ended up meriting a substantial post in itself. We'll cover adding dependency attributes to repository rules, generating .bzl files to resolve Labels, chaining together module extensions, and using macros in generated BUILD files. The former two options are relatively straightforward, but we cover the latter two options in case your use case requires them.

Such legacy WORKSPACE macros commonly seem to pertain to toolchain configuration, selecting repositories to instantiate based on user defined parameters. So we'll use a small example project to illustrate these solutions as they apply specifically to toolchain configuration.

In the next post, I promise to get into the tasty testing stuff, in what promises to be the third of a four part trilogy.

Boston: Around the World with Bazel in Watercolors

This article is part of the series "Around the World with Bazel in Watercolors".

Boston is my second favorite city, after New York, of course! More on why below. It was a 1.5 day trip to meet the Boston Bazel community on the way to NYC from another San Francisco visit. Given the short trip, I only got a chance to do a tiny watercolor - see the cultural notes. However, I’ve gone back to Boston during my family vacation in Cape Cod, so I have much more to share in the form of my daily watercolor inspiration from the various day trips we’ve done on the Cape!

Boston Watercolors

Migrating to Bazel Modules (a.k.a. Bzlmod) - Maintaining Compatibility, Part 1

As we're well aware by now, Bzlmod is the new hotness, and WORKSPACE is old and busted and going away in Bazel 9. However, Bazel 8 still supports WORKSPACE, and thus legacy WORKSPACE usage won't completely disappear for some years yet. Despite the Bazel community's efforts to help facilitate Bzlmod migrations (including this blog series), some projects may remain unable to migrate sooner than later.

What's more, publishing your repository for use by other projects raises the challenge of supporting a range of older and newer versions of its dependencies. Your repository should work with the newest versions of Bazel, rules_java, protobuf, and other dependencies in order to stay current. However, not every project that could benefit from the latest version of your repository will want to upgrade these other dependencies right away.

This post describes how to design a repository to remain compatible with both WORKSPACE and Bzlmod, and with newer and older dependency versions. Just as importantly, in the next two posts, we'll discuss testing approaches to help ensure that this remains the case.

Build Meetup in London – Recap

In May, we co-hosted the London Build Meetup with Tweag by Modus Create and Jane Street. Build system insights, stories about first-hand build challenges, and great conversations packed the afternoon and evening. The lineup covered everything from large-scale migration battles to new research. If you missed it, here’s what you need to know.