Skip to content

testing

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.

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.

Bazel Testing Tips

One of Bazel’s key features is that tests are treated as the same as other build actions. Bazel provides a uniform command line interface for running tests no matter the underlying language or test framework. While there’s much to be said about writing test rules and frameworks that mesh well with Bazel, this post will focus on the experience of running tests as a developer with bazel test. Running tests is a core software engineering workflow, so it’s not surprising Bazel has many useful features for iterating locally with a test.