Bazel

A quick tip for today:

Use Awesome Bazel to find new Bazel rulesets, tooling, and resources. Don’t be afraid to submit PRs to its GitHub repo.

Yesterday, I explained how you can wrap a bazel run target with a sh_binary() to execute arbitrary code both before and after the run target, which is particularly useful for retrieving secrets from a secret management system and passing them to the run target.

If you are passing secrets via environment variables that are retrieved by command-line programs, there’s an even easier way to do it – use the command rule from Atlassian’s bazel-tools repo and its raw_environment attribute.

An executable rule which can be executed via bazel run is the natural way to model interactions with external systems in Bazel such as uploading build artifacts to a remote artifact repository. For example, imagine a rules_artifactory ruleset which includes a rule artifactory_push() executable rule which uploads a compiled .dpkg to an Artifactory apt repository, or a rules_docker ruleset which has a rule docker_push() which pushes a Docker image to a remote image repository.

When I first started writing custom Bazel rules, I often created separate rules for the build and run commands in Bazel. This was a mistake.

When writing custom rules, you often need to invoke executables with argument lists. For example, let’s say you are writing a custom rule that executes gcc to compile a set of input source files. You could write:

Bazel started on Linux and Mac OS, and most people use Bazel on these platforms exclusively, but Bazel can execute on Windows as well. However, Windows has enough idiosynchatic differences that writing a single, operating-system agnostic rule that executes on both Windows and Linux/Mac is quite hard. Often it is easiest to have the rule detect whether it is running on Windows and execute different behavior.

When writing a custom rule that generates files, be sure to add prefixes to all filenames so that multiple instances of your rule can be instantiated within the same Bazel package.

One tends to write a lot of Bash scripts when using Bazel. In order to make these scripts more robust, enable Bash’s unofficial strict mode by starting all scripts like this:

Bazel requires all files to end with LF (not CR-LF) in order to work correctly.

If you are performing cross-platform Bazel development with Windows users, you can force this setting for all text files in your repo by creating a .gitattributes file with the following content:

Quick Bazel tip for today: If you want to build everything except for a specific subtree, you can prefix the subtree you want to exclude with a -.

For example, to build everything except for //client_access_library/...:

bazel build -- //... -//client_access_library/...