Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Since ./dev always builds dev unconditionally before doing anything else, that means there will be a slight delay before your build or test actually begins. Due to caching this pause should never be too long, but if it’s annoying you or you’ve found a way to thrash the cache, you can do:

Code Block
./dev build dev

...

(Note: the first time you run ./dev, dev will need to build itself, so be patient (smile)) ./dev build short also works as an alias. The first thing dev does is tell you what bazel command it’s running. Bazel will pretty-print build output to the terminal and assuming the build is successful, dev will symlink the binary to ./cockroach-short for you.

...

Code Block
# build "verbosely", outputting all commands as they are run
./dev build short -- -s

Running tests

Run ./dev test with the name of one or more packages to execute all tests from those packages:

Code Block
./dev test pkg/sql/types

If the test passes, you’ll see a brief message indicating which tests were run and their status:

Code Block
INFO: Elapsed time: 7.842s, Critical Path: 7.26s
INFO: 48 processes: 3 internal, 45 darwin-sandbox.
INFO: Build completed successfully, 48 total actions
//pkg/sql/types:types_test                                               PASSED in 0.7s

If the test doesn’t pass, Bazel will print the location of the test’s log file:

Code Block
INFO: Elapsed time: 8.763s, Critical Path: 7.94s
INFO: 46 processes: 1 internal, 45 darwin-sandbox.
INFO: Build completed, 1 test FAILED, 46 total actions
//pkg/sql/types:types_test                                               FAILED in 1.5s
  /private/var/tmp/_bazel_ricky/be70b24e7357091e16c49d70921b7985/execroot/cockroach/bazel-out/darwin-fastbuild/testlogs/pkg/sql/types/types_test/test.log

You can examine that file to see the complete logs for the test.

Tips and tricks

  • dev test has a --stress flag for running tests under stress.

  • Next to the test.log file produced by your test, you can find a test.xml file. This file contains specific information on each test run and its status, as well as timing information.

  • The -v argument to dev test will result in more verbose logging as well as more detailed information written to the test.xml.

Other tasks

Code Block
# Run benchmarks for pkg/sql/parser
./dev bench pkg/sql/parser
# Open a container running the "bazelbuilder" image. Requires Docker.
./dev builder
# Generate code (run this before submitting your PR).
./dev generate
# Run lints
./dev lint

dev vs. make

This is a (non-exhaustive) 1-to-1 mapping of dev commands to their make equivalents. Feel free to add to this (smile)

dev/bazel command

equivalent non-bazel command

./dev build cockroach

make build

./dev build short

make buildshort

./dev test

make test

./dev test pkg/sql/parser --filter TestParse

make test PKG=./pkg/sql/parser TESTS=TestParse

./dev bench pkg/sql/parser --filter BenchmarkParse

make bench PKG=./pkg/sql/parser BENCHES=BenchmarkParse

./dev builder

build/builder.sh

General Bazel tips

  • Bazel has a configuration file called .bazelrc. You can put a global configuration file at ~/.bazelrc or a per-repository file at .bazelrc.user in the root of your cockroach repo.

I just want to use Bazel directly 😠

...

  • dev adds --config=devdarwinx86_64 to Bazel invocations for macOS machines, and --config=dev for all other machines. The dev config tweaks a couple things under the hood for development builds, while the devdarwinx86_64 config pulls in a bespoke compiler that matches the version of Clang we use in CI. You probably want to put build --config=devdarwinx86_64 in your ~/.bazelrc or .bazelrc.user to match this same behavior.

  • dev strips out symlinks to ccache in your PATH, which break the Bazel build as ccache tries to write outside the sandbox.

  • In general, test targets are named after the package under test plus the suffix _test. For example: bazel test pkg/sql/parser:parser_test.