2.5.1 Strategies Abstraction
Bazel keeps two questions separate, building on 2.2.1 Loading, Analysis & Execution: "what actions are required to build these artifacts?" and "how should each of those actions be executed?" By the time a given action reaches execution, analysis has already planned that action in the action graph. An execution strategy is the layer that runs those planned actions locally, in a sandbox, through a long-lived worker, on remote machines, or by racing local and remote branches, without changing what the action is supposed to produce.1,2,3,4
Strategy starts after the build has been planned
In Bazel's artifact-based model, BUILD files and rules describe the desired artifacts and their dependencies, while Bazel owns scheduling and execution.1 Before a given action runs, rule logic has already registered that action and its declared inputs and outputs.2 Strategy does not rewrite that plan. It chooses the runtime environment for each action. This is why moving from a workstation build to a remote cluster is primarily a configuration and infrastructure change, not a BUILD-file rewrite.1,3,5
Why the separation matters
First, one repository can use different execution environments without forking its build logic. A small local build can stay on your laptop, a larger CI build can offload actions to remote workers, and expensive compilers can stay warm as persistent workers, while the underlying targets and actions remain the same abstraction.3,5,6
Second, Bazel can route different actions differently. The same invocation can prefer one execution mechanism for one class of actions and another elsewhere, and dynamic execution can even launch local and remote copies of the same action and let the first branch to finish determine the outcome.3,4 The concrete names and routing vocabulary come next in 2.5.2 Strategies & Mnemonics.
Hermeticity is the contract that makes switching safe
Strategy changes are only safe when they do not change the meaning of the build. Bazel's strategy model assumes that the same action run under different strategies produces the same outputs. Otherwise strategy choice would silently change the build result.3 That assumption holds only when the action is really governed by its declared inputs, tools, and configuration, which is exactly the principle from 2.3.1 Hermeticity.2,7,8
Sandboxing is the local reality check for that contract. It removes undeclared files from the action's staged view so host-only dependencies fail early instead of leaking into a cache entry or a remote build.7,8 Remote execution relies on the same discipline at cluster scale: workers can safely execute already-planned actions only when those actions are self-contained and deterministic.5,7 If a build succeeds only under an unconstrained local run but fails when sandboxed or remote, the strategy did not "break" the build. It exposed that the build description was incomplete.
Strategy is execution policy, not target definition
Because strategy is execution policy rather than target definition, teams can change it in configuration and infrastructure instead of cloning rules for each environment. That is the path from one developer laptop to 6.3 Remote Execution Infrastructure and later 6.4 Execution Modes and Persistent Workers tuning: keep the declared action model stable, then change the execution backend when scale or latency demands it.1,5,6 The configuration mechanics themselves live in 3.2 Project Configuration.
Keep "what" and "how" separate in your head. BUILD files, rules, and analysis answer what action must run. Strategies answer where and under what constraints Bazel runs that action. When those two layers stay cleanly separated, the same repository can move from local execution to sandboxes, workers, or remote execution without rewriting build logic. When they do not, strategy changes surface hidden dependency bugs instead of changing the desired build.1,3,7
Check your understanding · 3 questions
1.Why can a team switch from local execution to remote execution without rewriting their BUILD files?
Select one answer
2.True or false: the role of hermeticity in the strategy abstraction.
Choose True or False for each sentence
3.Which principle makes it safe to switch execution strategies without changing the meaning of a build?
Select one answer
Footnotes
-
Artifact-Based Build Systems — users declare artifacts and dependencies while Bazel controls scheduling and execution ↩1 ↩2 ↩3 ↩4 ↩5
-
Bazel Glossary — analysis vs execution phases, execution strategies, configuration, and mnemonics ↩1 ↩2 ↩3
-
What are Bazel's strategies? — strategies as the abstraction over subprocess execution and the invariant that strategy choice should not change action semantics ↩1 ↩2 ↩3 ↩4 ↩5 ↩6
-
Dynamic Execution — local and remote branches of the same action can run in parallel. The first branch to finish determines the outcome, even if that first completion is a failure ↩1 ↩2
-
Distributed Builds — remote execution distributes already-planned actions across workers and depends on self-contained, deterministic actions ↩1 ↩2 ↩3 ↩4
-
Persistent Workers — workers as an execution strategy for long-lived compiler processes ↩1 ↩2
-
Sandboxing — sandboxing as a strategy choice and as local rehearsal for remote execution ↩1 ↩2 ↩3 ↩4
-
Why Bazel? — correct builds depend on tracked inputs and isolated action execution ↩1 ↩2
