Page Comparison

...

This will place a binary at bin/dev and if bin is in your PATH, you can then omit the leading ./. In this document we’ll always spell ./dev with the leading ./ to squash ambiguity and for ease of copy-pasting.

Doctor, doctor

Before trying to build anything, run the following:

./dev doctor

If dev notices any issues with your system that might prevent you from being able to build, it will let you know and tell you how to fix it. Make sure to run dev doctor before you ask for help just in case it catches something you didn’t know about.

First steps: building cockroach

...

• 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.

• As with dev build, dev test allows you to pass additional arguments directly to Bazel by putting them after --: for example, dev test pkg/sql/types -- --verbose_failures --sandbox_debug.

Other tasks

# 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

...

We recommend dev because it takes care of some common pitfalls for you and because it has a less wordy CLI, but you’re still welcome to directly use Bazel. A couple notes for those of you who wish to avoid dev:

• 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 prints out the (relevant) calls to bazel it makes before it does so. You can therefore run dev once just to learn how to ask Bazel to perform your build/test and then just directly call into bazel on subsequent iterations.

• 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.

...