Bazel Knowledge Hub

P.2.2 Consequences of Artifact-Based

Bazel's artifact-based model is not merely a different syntax for build files. Once Bazel knows which artifacts each action consumes and produces, it can safely remember old results, fetch them from another machine, and keep unrelated work outside the current build. That is the practical payoff behind P.2.1 Task-Based vs Artifact-Based, and it is why the deeper mechanics later live in 2.4 Caching & Incrementality and 6.2 Shared Remote Cache.1,2,3

Reuse concrete outputs

Bazel caches the outputs of concrete actions together with the action identity needed to tell whether the same computation is being requested again, rather than merely recording that //app:server built once. If the inputs are unchanged, Bazel can reuse the old bytes. If one source file changes, Bazel rebuilds only the affected path and keeps the rest.1,4,5

That is the direct operational consequence of P.2.1 Task-Based vs Artifact-Based. A task-based system usually knows that some steps exist and in what order they run, but it often cannot prove whether the previous result is still semantically valid. Bazel can, because the action definition itself is part of the model.2,4,6

Shared bytes beat repeated work

Once outputs are keyed by their inputs, reuse no longer has to stay on one laptop. A remote cache lets developer machines and CI check whether an artifact already exists for the same target and input state, then download it instead of rebuilding it locally. Fine-grained artifacts matter here because low-level results can be built once and shared many times.3,7,8

This only works if the result is trustworthy. 2.3.1 Hermeticity explains the conditions that make an action result safe to reuse. The immediate consequence is simple: CI or another developer may download those bytes instead of performing the same computation again.3,9,10

Routine clean builds mean something is off

Task-based systems often teach engineers to fix strange build behavior by cleaning everything and starting over, because the tool cannot reliably model all the causes of stale outputs.6 With Bazel, you should never need to run clean for correctness. If cleaning fixes the build, the system was not correct.9

The command itself is still real and sometimes useful, and 1.1.6 bazel clean covers what it actually deletes. But needing it as part of normal workflow usually means Bazel was missing an input, a tool was non-deterministic, or the build was not hermetic enough to trust cached results.10,11

key takeaway

Artifact-based builds let Bazel remember exact action results instead of vague task history. That enables local reuse and, with shared infrastructure, reuse of the same bytes across machines. When that model is healthy, incremental builds feel ordinary and bazel clean remains exceptional. The separate scope and scheduling properties are mapped in P.2.4 Five Properties.1,3,9

Check your understanding · 3 questions

1.What does Bazel actually cache to enable reuse?

Select one answer

2.Which practical consequences follow directly from Bazel's artifact-based model?

Select all that apply

3.True or false: clean builds and trustworthy reuse.

Choose True or False for each sentence

Needing bazel clean as part of your normal workflow is a healthy sign that caching is working.
Routine clean builds usually point to a missing input, a non-deterministic tool, or a non-hermetic build.
Remote cache reuse is only safe if the same inputs produce the same outputs across different machines.
0 of 3 answered

Footnotes

  1. Artifact-Based Build Systems — output reuse, minimum rebuild set, and the distributed-scale payoff of artifact-based control ↩1 ↩2 ↩3

  2. Software Engineering at Google — Ch.18: Build Systems and Build Philosophy — why giving the system control over artifacts enables stronger guarantees than task scripting ↩1 ↩2

  3. Distributed Builds — remote cache sharing across users and artifacts keyed by target plus input hash ↩1 ↩2 ↩3 ↩4

  4. Bazel Caching Explained (4-part series) — artifact-first build graph, action-level reuse, and recomputing only the affected path ↩1 ↩2

  5. Skyframe — exact invalidation from changed inputs through the reverse transitive closure ↩

  6. Task-Based Build Systems — opaque tasks, weak incrementality, and the habit of cleaning to recover ↩1 ↩2

  7. Dependency Management — remote caching as the better alternative to manually publishing internal artifacts ↩

  8. How We Halved Go Monorepo CI Build Time — shared remote cache removing duplicated work across CI shards ↩

  9. Bazel Training 101 (Part 2): Bazel's Essential Properties — remote caching shares artifacts and clean should not be routine ↩1 ↩2 ↩3

  10. Bazel and action (non-) determinism — action identity, hidden inputs, and how non-determinism breaks trust in reuse ↩1 ↩2

  11. When to use Bazel? — practitioners describing "just clean it" as the bad old normal Bazel aims to avoid ↩

← PreviousTask-Based vs Artifact-BasedNext →Core vs Rulesets