You should still ask
dev doctorif your machine is up-to-snuff before you try to
bazel build. The checks it performs aren’t
dev doctoralso sets up a local cache for you.
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.
When running tests under stress, race, or
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.
If you want to build a test without running it, you must include the the
--config testargument to
bazel build. (
devtakes care of this for you if you are using it.)
Managing CPU resources available to a test under Bazel
Bazel, all tests under a given
Go package belong to the same test target. Test targets can be sharded into multiple shards and each shard will run a subset of the tests in a given test target. Shards can run in parallel but tests within each shard run sequentially.
By default, each shard gets 1 CPU core and as a result each test has 1 CPU core available to it. This can be adjusted by adding the following to the
go_test rule for that test target (found in
tags = ["cpu:n"]
Note: Adjusting the number of CPU cores using the method above will adjust the number of CPU cores available to all tests in that test target. If you need to adjust the number of cores for a single test (few tests), extract it into a separate package and adjust the number of cores there to avoid reserving extra CPU cores for tests that don’t need them.