0.1.4 Output Root

After your first bazel build, Bazel normally creates convenience symlinks at a writable repository root. They point into its output directory hierarchy¹, and their names or presence can be configured. Bazel keeps build artifacts outside the source tree², and the symlinks provide quick access to find them.

The Convenience Symlinks

With the default symlink prefix, four symlinks normally appear alongside MODULE.bazel (0.1.2 Repository Root) and your BUILD.bazel files¹:

my-project/
├── MODULE.bazel
├── BUILD.bazel
├── app/
│   ├── BUILD.bazel
│   └── main.cc
├── bazel-bin → ...            ← compiled outputs
├── bazel-my-project → ...     ← execution root
├── bazel-out → ...            ← configuration output tree
└── bazel-testlogs → ...       ← test logs

Bazel does not use these convenience symlinks internally¹. Their destinations are Bazel-managed state outside your source tree.

Path Mirroring

Output paths mirror the package structure (0.1.3 Package): the package part of the label becomes the subdirectory under Bazel's output trees. Most targets have one main output location. Tests are the common exception: Bazel builds the test program under bazel-bin/, then writes execution artifacts such as logs and XML under bazel-testlogs/¹.

The diagram below shows one runnable example, reproduced by the output-path-mirroring snippet. The sample files are representative, not exhaustive: real output directories often include helper files such as params files or test metadata.

One test target can have a built test executable in bazel-bin/ and a separate per-target artifact directory in bazel-testlogs/¹, so "one label -> one final file" does not describe tests.

Configurations Inside bazel-out

Inside bazel-out/, Bazel creates a subdirectory for each build configuration — a combination of target platform, compilation mode, and other settings¹:

bazel-out/
├── k8-fastbuild/
│   ├── bin/                ← compiled outputs (BINDIR)
│   └── testlogs/           ← test results
├── k8-opt/
│   ├── bin/
│   └── testlogs/
└── _tmp/
    └── actions/            ← stdout/stderr from build actions

The bazel-bin and bazel-testlogs symlinks point to one configuration at a time: the configuration of your most recent top-level build or test. Change flags such as -c opt, build for a different platform, or switch to a top-level target with a different configuration, and those symlinks may point somewhere else. Older outputs still remain in bazel-out/.

If you need the full picture, look in bazel-out/. It keeps one subtree per configuration, while bazel-bin and bazel-testlogs are just shortcuts into one of them.

Why Outputs Live Outside the Source Tree

Keeping generated state separate prevents outputs from masquerading as inputs and lets several configurations coexist without overwriting source files³. Edit files under the repository tree, but treat bazel-* entries as generated views managed by Bazel.

When you need an exact managed path, ask Bazel with the commands in 1.1.7 bazel info. Before deleting generated state, read 1.1.6 bazel clean to see what the cleanup commands actually remove. You do not need to understand the action cache or server lifecycle just to find a freshly built artifact.

Gitignoring Output Directories

The convenience symlinks should be excluded from version control:

/bazel-*

This catches all four convenience symlinks: bazel-bin, bazel-out, bazel-testlogs, and bazel-<project-name>¹.