> ## Documentation Index
> Fetch the complete documentation index at: https://site.aspect.build/llms.txt
> Use this file to discover all available pages before exploring further.

# The ‘build' and ‘run’ commands

> Learn how the Bazel build and run commands work, including useful flags like --config, --jobs, and --keep_going, and how bazel run executes binary targets.

## 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:

```bash theme={null}
bazel run //path/to:target.push
```

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](/blog/run-tools-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.

<Note>
  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.
</Note>

### Scripting-Friendly Output Queries

For automated workflows, you can locate outputs programmatically:

```bash theme={null}
bazel cquery --output=files //path/to:target
```

This command provides reliable paths to artifacts under bazel-out for scripting and further processing.