genrule chooses script based on host platform rather than execution platform

[jayconrod]

Description of the bug:

I have a macOS host machine, and I'm using a remote execution service with Windows executors.

This works for normal actions (at least those that avoid Bash or are conscious to use Powershell), but it fails for genrule. genrule has attributes cmd_ps, cmd_sh, cmd_bat, cmd. Bazel selects either cmd_ps or cmd_bat if the host machine is Windows and falls back to cmd.

It should select the script based on the execution platform, not the host platform.

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Below is a small example, as self-contained as I could get it. To reproduce, you'll need a remote execution service with Windows machines though, which I expect is rare.

-- BUILD --
genrule(
    name = "hello",
    outs = ["hello.txt"],
    cmd = "do_not_run",
    cmd_ps = "Set-Content -Path $@ -Value 'hello'",
)

platform(
    name = "windows_amd64",
    constraint_values = [
        "@platforms//os:windows",
        "@platforms//cpu:x86_64",
    ],
    exec_properties = {
        "Pool": "windows",
    },
)
-- .bazelrc --
build:engflow --remote_cache=grpcs://kyanite.cluster.engflow.com
build:engflow --remote_executor=grpcs://kyanite.cluster.engflow.com
build:engflow --bes_backend=grpcs://kyanite.cluster.engflow.com
build:engflow --bes_results_url=https://kyanite.cluster.engflow.com/invocation/
build:engflow --tls_client_certificate=/Users/jay/.secrets/kyanite.crt
build:engflow --tls_client_key=/Users/jay/.secrets/kyanite.key

build:windows --platforms=//:windows_amd64
build:windows --host_platform=//:windows_amd64

Run with:

bazel build --verbose_failures --subcommands --config=engflow --config=windows //:hello

Error output:

SUBCOMMAND: # //:hello [action 'Executing genrule //:hello', configuration: d4de5ce9c2e00ceef8dc814dd8ca9ff265a3fbf8cd39f29d25d353798e0aaa0a, execution platform: //:windows_amd64]
(cd /private/var/tmp/_bazel_jay/6ed3f141bd98e3e79c69ec8eab59bdfb/execroot/__main__ && \
  exec env - \
    PATH=/Users/jay/Library/Caches/bazelisk/downloads/bazelbuild/bazel-6.2.1-darwin-arm64/bin:/Users/jay/bin:/opt/go/installed/bin:/opt/google-cloud-sdk/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/opt/apache-maven-3.8.6/bin:/opt/prometheus-2.37.0-rc.0.darwin-arm64:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/jay/go/bin:/Users/jay/Code/depot_tools:/opt/homebrew/opt/[email protected]/libexec/bin \
  c:/tools/msys64/usr/bin/bash.exe -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; do_not_run')
# Configuration: d4de5ce9c2e00ceef8dc814dd8ca9ff265a3fbf8cd39f29d25d353798e0aaa0a
# Execution platform: //:windows_amd64
ERROR: /Users/jay/Code/scratch/BUILD:1:8: Executing genrule //:hello failed: (Exit 34): Remote Execution Failure:
Internal: ChALVi9MaQ9CrKDcc0LvhbMMGiUKINzUijJzaXveNWnRcW7SmwOuDFuRH4-t-7h1pNt9R0fHEKAB: ERROR: external/bazel/src/main/native/windows/process.cc(202): CreateProcessW("c:\tools\msys64\usr\bin\bash.exe" -c "source external/bazel_tools/tools/genrule/genrule-setup.sh; do_not_run"): The system cannot find the file specified.
 (error: 2)

Which operating system are you running Bazel on?

macOS

What is the output of bazel info release?

release 6.2.1

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

n/a

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

n/a

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

Not as far as I know

Have you found anything relevant by searching the web?

no

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

Loosely related issues

• Bazel on Windows: improve first-time experience #5254
• Better bash-less Windows support in actions.run_shell: add command_bat, command_ps #15194
• [BUG] tools in genrule can not be built with alternative toolchain / platform #12942

[tjgq]

This is probably because of this TODO. I'll look into fixing it.

[jayconrod]

Thanks! Really appreciate the quick fix. I've verified this works in our remote cluster.