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...
Let’s say you are using Bazel to build a C program which links against a system-provided version of libcurl, the multiprotocol file transfer library. What is the best way to link your program against this library within Bazel? This blog post provides an answer to that question.
Read more...
This post describes a pattern for implementing a continuous integration (CI) pipeline using Bazel. This pattern is my starting point whenever I set up a new Bazel-based project in CI, after which I add any project-specific pipeline customizations.
This pipeline is purely about the CI (build to release) stages of a pipeline. A full continuous delivery (CD) pipeline, which includes deployment, will be discussed in a later post.
Read more...
In Bazel, a successful build should be a quiet build. While build failures
should, of course, print ample information to stderr to aide in troubleshooting,
any custom Bazel code you write should not output progress information to stdout
or stderr. Let Bazel be responsible for overall build progress reporting.