- Intentionally non-hermetic tests can be tagged with
external. This tells Bazel that the test depends on undeclared systems (such as a service you’ve deployed before runningbazel). It won’t be cached, since any cache key would obviously be inadequate to determine when the test needs to be re-executed. - The spawn strategies we mentioned in the previous section try to enforce hermeticity. You might have a legitimate reason to run with
--spawn_strategy=localfor example, if you want to run a build without having to declare dependencies, such as when you bridge Bazel to a legacy build tool that doesn’t have a correct dependency graph.
Bazel 201: The way Bazel works
Hermeticity: trade-offs
Understand the trade-offs of Bazel hermeticity, including external test tags and spawn strategies that relax sandboxing for legacy or non-hermetic workloads.
Bazel often gets conflated with the dogma of how Blaze is used in google3, Google’s internal monorepo. Hermeticity is an example: Googlers usually expect a build to be completely hermetic. But Bazel doesn’t actually require this.