dev because it takes care of some common pitfalls for you and because it has a less wordy CLI (especially for tests), but you’re still welcome to directly use Bazel. A couple notes for those of you who wish to avoid
You should still ask
dev doctorif your machine is up-to-snuff before you try to
bazel build. The checks it performs aren’t
devprints out the (relevant) calls to
bazelit makes before it does so. You can therefore run
devonce just to learn how to ask Bazel to perform your build/test and then just directly call into
bazelon subsequent iterations.
devstrips out symlinks to
PATH, which break the Bazel build as
ccachetries to write outside the sandbox. If you use
bazeldirectly you should get the
ccachelinks out of your
PATHmanually (i.e. uninstall
If you want to build with the UI, you must include the
--config with_uiargument to
devchecks whether your executable should include the UI bits and passes it in for you.
In general, test targets are named after the package under test plus the suffix
_test. For example:
bazel test pkg/sql/parser:parser_test. Note that there are exceptions:
pkg/roachpb:string_testis one, and more may be added later.
When running tests under stress, race,
devdoes the legwork to invoke with the necessary flags with bazel. This involves running under another binary (
stress), running with certain gotags (
race), or allowing certain paths outside the bazel sandbox to be written to (
testdata). Feel free to see the actual
bazelcommand invoked and tweak as necessary.