Skip to content

Latest commit

 

History

History
53 lines (38 loc) · 2.39 KB

2023-12-07-remote-local-fallback-respects-declarations.md

File metadata and controls

53 lines (38 loc) · 2.39 KB
Raw
Error in user YAML: (<unknown>): found character that cannot start any token while scanning for the next token at line 6 column 8
---
created: 2023-12-07
last updated: 2023-12-12
status: Under Review
reviewers:
  - tjgq
title: `--remote_local_fallback` Respects Strategy Declarations
authors:
  - Silic0nS0ldier
---

Abstract

The flag --remote_local_fallback makes it possible for remotely executed action spawns that fail to fallback to the local spawn strategy. This proposal seeks to treat spawn retries identically to actions tagged with no-remote.

Background

Falling back to the local environment is not always safe, and may be contrary to spawn strategy configuration.

e.g.

# Denotes actions with the mnemonic `FOO` must always be spawn with the `remote` strategy
build --strategy=Foo=remote

Requiring that an action be only spawned remotely may reflect a technical limitation. Such as the remote offering a Windows environment while Bazel itself is running on a macOS machine. The Windows binaries cannot be reasonably expected to work on macOS, and compatibility layers to support such a scenario are unlikely to provide identical behaviour.

Even in a context where remote and local environments are identical, local may not represent the optimal spawn strategy.

  • worker may offer better performance, especially if several remotable actions fail (e.g. connectivity loss).
  • sandboxed may provide an environment closer to that of the remote.

Related Issues

Proposal

A new flag --incompatible_strict_remote_local_fallback will be introduced which when flipped makes --remote_local_fallback rerun spawn strategy selection with remote ignored.

This means;

  • All registered strategies along with their filters are considered (--spawn_strategy, --strategy, --strategy_regexp, etc).
  • If a remote spawned action has no local fallback, no attempt to spawn locally is made and the build fails.
  • The --remote_local_fallback_strategy flag will have no effect. Note that it is incorrectly documentated as a no-op in Bazel 7.0.0 (see #15519 (comment)).

Backward-compatibility

Current behaviour is counterproductive, so the expectation is that flag guarded behaviour would become the default in the next major version of Bazel.