Should @local_config_platform//:host be marked no-remote-exec (or maybe even no-remote)?

[EdSchouten]

Description of the feature request:

As of #22363, we have testing coverage in place for ensuring platforms as a whole can be marked no-remote-exec. This raises the question: should the default host platform be marked as such?

Think of it like this: the default host platform does not have any remote execution platform properties set up. This means that if such a platform were to be used for remote execution, it would likely just result in an error indicating that no workers exist having the empty set of platform properties. By marking it as no-remote-exec, we're essentially forcing the user to declare its own platform that has the right properties set.

Maybe we should even consider marking it no-remote. If a remote cache is shared between users running different operating systems, it isn't safe to upload actions that don't have platform properties set. But maybe that complicates the onboarding experience.

Which category does this issue belong to?

No response

What underlying problem are you trying to solve with this feature?

I've got a simple remote execution cluster that only has Linux workers, which I want to use from my Mac to speed up builds where possible. However, there are some actions that only run on macOS, which I want to run locally. So I declare two platforms:

platform(
    name = "remote_linux",
    constraint_values = [
        "@platforms//cpu:x86_64",
        "@platforms//os:linux",
    ],
    exec_properties = { ... },
)

platform(
    name = "local_fallback",
    exec_properties = {"no-remote-exec": "true"},
    parents = ["@local_config_platform//:host"],
)

And then call Bazel with --extra_execution_platforms=//:remote_linux,//:local_fallback. If @local_config_platform//:host itself were marked no-remote-exec, I could get rid of that second platform declaration.

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

7.x

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[sluongng]

Given the current observed behavior in #23037, and several related questions/discussions around this topic in:

• test_exec_properties differentiation #10799 (comment)
• Support running tests on the target platform #17390
• Execution Platform Scoped Spawn Strategies #20497
• https://bazelbuild.slack.com/archives/C01E7TH8XK9/p1721781699224499

We should hold off on promoting this usage pattern until we figure out how to address the test's execution platform. On our end, we are seeing remote test actions sent to our RBE server with "no-remote-exec": "true" which is very confusing to our users.

---

The current usage pattern also a bit overlap with dynamic execution. One could set up the build so that the action is executed both remotely and locally, where remote exec points to a non-existent pool of workers and never gets executed, forcing it to be run locally instead.

---

Finally, semi-related but I hope we can get a bit more telemetry data about platforms and toolchains via #23019. It would help us build tools to help detect badly configured platforms/toolchains.