2.2.2 Reading Build Output
Non-zero exit codes from 1.1.9 Exit Codes mean Bazel reported a problem. The build log tells you where it failed. Bazel still has the three responsibilities from 2.2.1 Loading, Analysis & Execution, and the INFO: Analyzed target ... line (or INFO: Analyzed N targets ...) is a useful clue: Bazel completed analysis for the named targets. It is not proof that no execution began earlier, because 2.2.4 Skymeld can run ready actions while analysis of the remaining request continues.1,2
Read the headline lines first
INFO: Analyzed target //foo:foo (14 packages loaded, 48 targets configured).
INFO: Found 1 target...
Target //foo:foo up-to-date:
bazel-bin/foo/foo
INFO: Elapsed time: 9.905s, Critical Path: 3.25s
INFO: Build completed successfully, 6 total actions
The first headline is the pre-execution summary. packages loaded is loading work: how many packages Bazel had to read to understand the request's reachable closure. targets configured is analysis work: how many configured targets Bazel had to validate and turn into an action plan.1,2 If a small-looking target reports a surprisingly high package count, that usually means the requested slice is wider than you expected, not that execution suddenly became slow. That is the same reachability story from 2.1.2 Laziness & Slicing, now exposed in the log.1
Treat the analyzed-summary line as the main boundary
Loading and analysis are distinct phases, but loading can interleave with analysis while the target graph is being built up.2 For everyday debugging, the practical question is therefore: did Bazel reach an INFO: Analyzed ... summary line (Analyzed target ... or Analyzed N targets ...)?
If the answer is no, stay on the BUILD-side of the world. Look at BUILD / .bzl evaluation, package resolution, dependency declarations, and other rule-validation problems instead of jumping straight to compiler output.1 This is where the message families from 1.1.10 Common Error Messages live. Load- or analysis-time failures often never print INFO: Analyzed ... at all. The log may jump straight to FAILED: Build did NOT complete successfully (...) with partial counters. (Execution failures can still print an analyzed summary first, then fail later in the log.)
If the answer is yes, analysis succeeded and Bazel has a valid action plan, the boundary that 2.2.3 Static Action Graph sharpens. Failures after that point are execution failures: compiler or linker errors, test failures, missing inputs to executed tools, or tools that produced the wrong outputs.1 When the summary line is too terse, the next debugging tools live in 2.3.4 First-Response Debugging Flags.
Read the counters together, not in isolation
Build completed successfully, K total actions is the execution-side summary, but it is not a pure "how many compilers ran" counter. In a null build, Bazel reports 0 packages loaded, 0 targets configured, and still ends with 1 total action.1 The important signal is the combination of numbers: near-zero loading and analysis counts plus an immediate success message means Bazel reused prior work, which is the operator-visible effect behind 1.1.3 Server/Client Architecture and later 2.4.1 Skyframe & Incrementality.
During execution, Bazel can also print progress messages showing the current step and completed-versus-total actions.1 Read those as "how much of the planned work remains," not as a separate fourth phase. Modern Bazel may start ready actions while analysis of the whole request is still finishing, as 2.2.4 Skymeld explains, so the log is not always three non-overlapping time blocks. The responsibilities stay distinct: loading discovers packages, analysis configures targets and registers actions, and execution runs ready actions.
Read Bazel output in this order: first ask whether it reached an INFO: Analyzed ... summary line, then read the counters in phase order. packages loaded explains loading scope, targets configured explains analysis scope, and total actions tells you how much execution work the request needed. That one habit usually narrows your first debugging move to the right layer before you inspect the rest of the log.1,2
Check your understanding · 3 questions
1.In Bazel's build output, what does it mean when packages loaded and targets configured are both near zero but total actions is 1?
Select one answer
2.True or false: interpreting Bazel console output.
Choose True or False for each sentence
INFO: Analyzed target ... line, that strongly suggests a loading or analysis failure, but it does not prove that no ready action began under Skymeld overlap.packages loaded count always indicates that many source files were compiled.3.An operator builds a small-looking target and the headline reads INFO: Analyzed target //tiny:bin (210 packages loaded, 480 targets configured). What does the surprisingly high packages loaded count most likely indicate?
Select one answer
Footnotes
-
Build programs with Bazel — sample build output, progress counters, null-build example, and the user-facing loading / analysis / execution breakdown ↩1 ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8
-
Bazel Glossary — precise definitions of loading, analysis, execution, configured targets, and the note that loading can interleave with analysis ↩1 ↩2 ↩3 ↩4
