bazelrc files Last updated May 5, 2022

OBazl convention:

Create or edit .bazelrc (in the project root directory, which should also contain WORKSPACE.bazel), adding as the final line: try-import dev/user.bazelrc. This file should go under version control.
Create dev/.gitignore and put it under version control.
dev/.gitignore should contain one line: *. This keeps dev/ under version control so it is available to all developers, but everything it contains is gitignored, so developers can use it for private files like user.bazelrc.
Create dev/user.bazelrc and populate it ad libitum.

At a minimum you will probably want to add the following to your user.bazelrc.

common --color=yes
build --subcommands=pretty_print
build --verbose_failures
build --sandbox_debug

The common command makes the option apply to all Bazel commands (e.g. build, query, etc.). The build options listed only apply to the build command, which is why they do not use common.

You can control these with a command line flag by adding a "grouping" suffix. For example, if you prefer to usually build without these debugging options, but want to be able to flip them on with a command line switch, you can add a suffix like :dbg

build:dbg --subcommands=pretty_print
build:dbg --verbose_failures
build:dbg --sandbox_debug

Then to enable the options pass --config=dbg on the command line.

You can use user.bazelrc to override remote repo references, redirecting resolution to a local copy. For example, if you wanted to develop rules_ocaml, you would fork/clone a copy to your local system, say in $HOME/bazel/rules_ocaml, and then add an override to user.bazelrc, using an absolute path:

common --override_repository=rules_ocaml=/home/<UID>/bazel/rules_ocaml

This tells Bazel to resolve all references to the @rules_ocaml namespace to your local copy.