Downloading a private release asset from GitHub given only its name and tag requires a complicated series of interactions with the GitHub API. This blog post explains how to write two repository rules which make dealing with private release assets in Bazel easy.
Read more...
A quick tip on how to execute multiple run commands in parallel.
Read more...
This blog post explains how to use a custom C++ toolchain based on clang 12 with libc++-12 in Bazel on Ubuntu 20.04.
Read more...
Bazel supports scaling out builds with a remote execution system. Unfortunately, it is very easy for ruleset authors to release rules that work when executed locally but do not work when executed remotely. This blog post explains ruleset authors can set up a simple remote execution system to verify that their rulesets work correctly.
Read more...
In Bazel, stamping is the process of embedding additional information into built
binaries, such as the source control revision or other workspace-related information.
Rules that support stamping typically include an integer stamp attribute, where
1 means “always stamp”, 0 means “never stamp”, and -1 means “use the Bazel
build --stamp flag. This blog post explains how to write a rule that supports
these values.
Many Bazel attributes support the use of predefined variables
and functions such as @D for output directory or
$(location //foo:bar) to get the path to a label. But what
if you want to apply some sort of tranformation to these
variables, or define your own custom make variables? This
blog post explains how.
Bazel developers are currently working on adding the ability to
retrieve secrets using a credential-helper executable, similar
to how other tools like Docker and Git handle managing secrets.
Until then, the recommended approach is to store secrets in
~/.netrc. This blog post explains how to write a custom Bazel
rule which reads secrets from ~/.netrc.
In general, one should never check in binary artifacts into Git; it is better
to retrieve them from an artifact repository or a website using http_archive().
However, sometimes convenience is more important than ideological purity.
To handle these cases, I wrote a simple workspace rule named local_archive().
When writing Bazel tests using sh_test(), I often find myself needing to compare
two collections for equivalence. For example, I might compare a directory listing
against a set of expected files or directories, or the list of files and directories
in a .tar file against a set of expected items. This blog post provides some tips
and tricks as to how to do so.
Dealing with Bazel runfiles is one of the most annoying things about using Bazel. Fortunately, Bazel provides a library to make resolving runfiles from Bash scripts easy.
Read more...
sh_test is my most commonly used test rule by far. It is the easiest way to
write quick-and-dirty tests and works nearly everywhere. For anything beyond
the most trivial tests, I use Bazel’s Bash unit test framework. This explains
what the framework is and how to use it.
A quick tip for today:
When creating a new ruleset, particularly on GitHub, start with the official Bazel rules template. It includes a number of features out of the box that are rather tiresome to implement yourself.
Read more...
At work, we have a number of custom-written Bazel rulesets stored in organization repositories on GitHub1. This post explains how we use these non-public rulesets in our Bazel projects.
Read more...
For most Bazel projects, I strongly recommend using a single Bazel workspace per source code repository. However, it can be occasionally useful to nest multiple workspaces within a single repository. For example, when I’m writing Bazel rulesets, I will often create test cases that contain own workspace with a slightly different configuration in order to test various workspace-level configuration settings for the ruleset, while maintaining a root workspace which is the primary workspace for the ruleset.
Read more...
Bazel users commonly need to manage multiple different configurations when building and testing software, such as:
As developers know, virtually all compilers support the notion
of compilation mode, e.g.. whether to compile the code in debug
or release mode. In Bazel, this concept is built natively into
the build system itself. When compiling software using bazel build,
one can select a compilation mode using the --compilation_mode
(often shorted to -c) flag.
When writing a custom Bazel ruleset, it is important to carefully separate its public interface from its private implementation and be deliberate and careful about changes to the public interface. Here’s the pattern I use when I’m writing rulesets to handle this.
Read more...