Bazel Knowledge Hub

1.1.5 --keep_going (-k)

Server mechanics explain why Bazel can be fast. --keep_going addresses a different operator concern: what happens when things fail across a broad target set. By default Bazel is fail-fast: the execution phase stops at the first error. With -k, Bazel keeps going as far as it can — across both analysis and execution — building every target whose prerequisites succeeded1,2. In practice, that turns a broad 0.2.3 Target Patterns sweep into a fuller damage report instead of a single first failure3,4.

What It Changes

Without -k, a broad command such as this stops as soon as Bazel hits the first build error:

bazel build //...

With --keep_going, Bazel still fails the command overall, but it tries to finish every target whose prerequisites were built successfully1. That means unrelated packages can continue, while targets downstream of the failure still stop because their dependency chain is broken. The failed command reports a more complete set of independent problems.

The same idea applies one phase earlier as well. If you requested several targets and only some of them make it through analysis, --keep_going lets Bazel continue into execution for the subset that analyzed successfully1. This is why the flag is most useful on wide builds, wide tests, and repo-scale sweeps rather than on a one-target command.

When To Reach For It

Use --keep_going when breadth of feedback is more valuable than the very first failure: a repository-wide bazel build //..., a large bazel test //..., a refactor that may have broken several packages, or a CI job that should show the full breakage set in one pass3,4.

bazel test //... --keep_going

It pairs naturally with 1.1.10 Common Error Messages, because one run may surface missing deps, visibility problems, and compile failures together1,3. Later, 2.2.2 Reading Build Output explains how to separate loading, analysis, and execution failures in that output4.

The command still exits non-zero when failures exist, so automation should treat -k as a reporting aid, not as a success mode. The Level 1 view of that contract is 1.1.9 Exit Codes. The CI-heavy version comes later in 3.6.3 CI-Specific Flags & Exit Codes5.

bazel test Has Its Own Knob

Test outcome handling has a separate flag from --keep_going: --test_keep_going. Tests run to completion by default. Disabling test_keep_going makes Bazel abort on the first non-passing test, and --notest_keep_going should not be combined with --keep_going1. For now, -k helps broad test sweeps continue through build and analysis trouble, while test-specific stop behavior belongs with 1.2 Testing Strategy.

extra

Query Results Can Be Partial

bazel query also accepts --keep_going to continue past errors such as missing targets and keep making progress1,6. That is useful in tooling and large-repo exploration, especially for broad rdeps, cquery, and aquery workflows where small pockets of breakage should not stop the whole inspection pass7,8.

The trade-off is trust. Query exit code 3 means partial success: the command returned something, but the result is not fully reliable, likely because --keep_going let query continue after errors5. So in query-heavy tooling, -k should come with a warning that the result is best-effort. The deeper query family belongs later in 5.2 Query.

key takeaway

--keep_going tells Bazel to finish as much independent work as still makes sense after a failure. Use it when one command targets many packages and you want one run to teach you about the full breakage set. The command still fails overall while reporting more useful information.

Check your understanding · 2 questions

1.True or false: --keep_going behavior.

Choose True or False for each sentence

It lets independent requested work continue after a failure.
It changes a command with failures into a successful exit.
It is most useful on wide requests where several independent problems may exist.

2.What does bazel query --keep_going exit code 3 mean?

Select one answer

0 of 2 answered

Footnotes

  1. Commands and Options — --keep_going semantics in execution and analysis, query behavior, and the separate --test_keep_going flag ↩1 ↩2 ↩3 ↩4 ↩5 ↩6

  2. Bazel flag cheat sheet — Bazel is fail-fast by default, and --keep_going tells it to continue as far as possible ↩

  3. Bazel Training 101 (Part 11): The 'build' and 'run' commands — practical -k usage: show all failures instead of stopping at the first one ↩1 ↩2 ↩3

  4. How to set up a Bazel testing configuration: comprehensive guide for Scala and Java — CI motivation for collecting all failures in one run ↩1 ↩2 ↩3

  5. Calling Bazel from scripts — query exit code 3 means partial success and unreliable results, commonly due to --keep_going ↩1 ↩2

  6. Query guide — bazel query --keep_going for continuing past missing-target and load errors ↩

  7. Deep dive into Bazel queries: from basics to advanced use cases — practical keep-going guidance for query, cquery, and aquery in large repos ↩

  8. Bazel Query Deep Dive: From Basics to Advanced Use Cases - Łukasz Wawrzyk, VirtusLab — use --keep_going for robustness with rdeps, cquery, and aquery ↩

← PreviousInspecting Server StateNext →bazel clean