Skip to main content

​
Build

Use build to populate the bazel-out tree with requested output files. This is most commonly used to answer the question, “Does the code compile”. For example, bazel build //path/to/package:* There are many flags to control building. Here are a few useful ones:
  • --nobuild means to perform a “dry-run” of the build. Use this to reduce noise when Bazel errors in a way that indicates it cannot load or analyze the BUILD files or rulesets.
  • --config=<name> lets you select a predefined configuration from the .bazelrc file
  • --jobs=<n> can be used to reduce Bazel concurrency so it uses fewer resources on your computer.
  • --keep_going / -k will continue building even after some targets fail.
  • --sandbox_debug skips the automatic deletion of temporary “sandbox” folders Bazel creates, so you can inspect them manually to debug failures.
  • --build_tag_filters lets you skip building certain targets that would otherwise match the target pattern. Note that bazel query <expression> | xargs bazel build is a more powerful way to customize which targets to build.
  • --action_env=<key[=value]> allows you to propagate environment variables to be seen by actions, however, the rule implementation must opt-in to this, see use_default_shell_env

​
Run

Running programs in Bazel really means build this program, then run it immediately. It is essentially syntactic sugar for:
Build this target, then spawn the resulting executable.
Any target with a name ending in *_binary is conventionally executable and can be run with bazel run. Other targets may also be executable; check the documentation for each ruleset. If you want to do some next steps with the resulting artifact, like load it into a container daemon or push it to a cloud provider, the best approach is to let Bazel run whatever that next step is:
Many rulesets provide convenient runnable targets, such as oci_push, for uploading to a container registry. Unlike bazel build or bazel test, the bazel run command allows non-hermetic side effects, such as writing build outputs back to the source tree. This is useful for workflows that require interaction with external systems. Programs under bazel run will see extra environment variables:
  • BUILD_WORKING_DIRECTORY is the absolute path to the working directory where bazel run was invoked
  • BUILD_WORKSPACE_DIRECTORY is the absolute path to the Bazel repository root.
To run arbitrary tools, read the Run tool installed by Bazel.

​
Locating Outputs

Sometimes, your workflow requires you to build the artifact and then locate the output file. The terminal output of bazel build will print paths to the resulting artifacts beneath the bazel-out tree.
By default, Bazel is configured to leave outputs on a remote cache service. This configuration is called “build without the bytes”. In this case, the outputs aren’t local, and you need to re-build with different flags or use a remote output service like bb-clientd to download them.

​
Scripting-Friendly Output Queries

For automated workflows, you can locate outputs programmatically:
This command provides reliable paths to artifacts under bazel-out for scripting and further processing.