Bazel spawn strategy selection for non-host exec platforms

.bazel-spawn-strategy-selection-for-non-host-exec-platform

.bazelrc

.envrc

use nix -p bazel_6

.gitignore

bazel-
.direnv

BUILD.bazel

genrule(
    name = "bleh",
    srcs = [],
    outs = ["yo"],
    cmd = "echo   foo > $@",
    executable = False,
    exec_compatible_with = [
        # "@platforms//os:macos"
    ],
)

platform(
    name = "not_local",
    constraint_values = [
        "@platforms//os:macos",
        # "@platforms//os:linux",
    ],
    # tags = [""],
    # visibility = [""],
    exec_properties = {
        "no-remote": "true",
        "no-sandbox": "true",
    },
)

gistfile1.txt

x

repo_rules.bzl

def _test_repo_impl(rctx):


test_repo_impl = repository_rule(
    implementation = _test_repo_impl,
)

WORKSPACE.bazel

workspace(name = "spawn_strategy_selection_test")

# We're testing if Bazel will skip the local spawn strategy if a target resolves
# to an execution platform that does not match the host platform.
#
# This is of interest because a convenient way to model remote build machines
# for RBE is as _execution platforms_ which, when selected, in turn cause
# different toolchains to be resolved. This lets us model system differences
# (i.e. different absolute library paths, host compiler versions, etc.) in an
# elegant way.
#
# However spawn strategy (i.e. sandboxed, worker, dynamic, remote, standalone,
# etc.) does not get to participate in the execution platform selection for
# targets. Instead the spawn strategy is picked during _execution_ — i.e. after
# the execution platform and toolchains are resolved (during configuration) for
# a particular target.
#
# This can lead to awkward situations like a target being configured to use the
# remote execution platform (i.e. because it is first in the list of
# `--extra_platforms` or because the target has constraints that require the
# execution platform) but it being spawned locally anyways (i.e. because
# `--spawn_strategy` is set to `local,remote`).
#
# We can prevent the converse situation (local platform is selected, spawn
# selection attempts to run the actions on remote) from arising using
# `exec_properties` on the local platform that are propagated to configured
# actions as `execution restrictions` — setting `no-remote-exec` will ensure
# that spawn strategy selection picks the `local` strategy.
#
# However we do not have a way to prevent the first scenario: there is no
# `no-local-exec` or `force-remote` execution restriction.
#
# Fortunately Bazel knows to consider ...

# Nevermind, it does not: https://github.com/bazelbuild/bazel/blob/79745b4db3ca8ab42451f9eb212994a340e3f7c9/src/main/java/com/google/devtools/build/lib/exec/local/LocalSpawnRunner.java#L176-L179
# sigh

# Demonstrate
# Show targets that are forced local
# Show targets that are forced remote
#
# Show the matrix
# Show that you can set things up to both "prefer remote" and "prefer local" exec.

addressed in this design doc (not yet implemented, dropped): https://docs.google.com/document/d/1U9HzdDmtRnm244CaRM6JV-q2408mbNODAMewcGjnnbM/edit#heading=h.5mcn15i0e1ch, tracked in: bazelbuild/bazel#11432

previously: https://github.com/bazelbuild/proposals/blob/main/designs/2019-06-25-platforms-strategies.md

also see: 1, 2

and this issue thread for a demonstration of the thing we're trying to sidestep here