Bazel transitions result in unix bash path returned on windows host

[peakschris]

Description of the bug:

I'm attempting to get windows tests to pass on rules_oci. This module uses many transitioned targets.

Building case4_transition with Bazel 8.3.1 or 8.4.1 on Windows:

# Case 4: Transition an oci_image and feed to oci_tarball
oci_image(
    name = "case4",
    architecture = "arm64",
    os = "linux",
)

platform_transition_filegroup(
    name = "case4_transition",
    srcs = [":case4"],
    target_platform = "//examples:linux_arm64",
)

results in ctx.toolchains["@bazel_tools//tools/sh:toolchain_type"].path returning /bin/bash instead of C:\msys64\usr\bin\bash.exe as set in BAZEL_SH envvar. This results in the bat wrappers generated for windows failing with invalid path.

Is there any way to get the @bazel_tools//tools/sh:toolchain_type without it being interfered by the transition?

This is only an issue with bazel 8; bazel 7.6.1 returns the windows bash.exe

Thanks! Chris

Which category does this issue belong to?

No response

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

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

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 ?

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

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

[fmeum]

This is expected: You are transitioning the target platform to Linux, so the runtime shell toolchain will be resolved for that platform. Since your host is Windows, BAZEL_SH will be ignored and the default path for Linux is used.

If rules_oci needs the path of a shell to run within the build (not at runtime), it would need to transition to the exec configuration first before obtaining the toolchain. Alternatively we would need to introduce a new toolchain type on rules_shell to support this use case.

[peakschris]

Thanks fmeum; this is basically for every rule that I'm porting to Windows; when creating the bat wrapper I need to know reliably:

1. if the build machine is windows (including logic that handles RBE cross compilation cases)
2. the path to bash on the build machine

The traditional approach for 1) is to use is_windows = ctx.target_platform_has_constraint(ctx.attr._windows_constraint[platform_common.ConstraintValueInfo]) which does not handle transitioned targets correctly.

I've got an approach for 1 that @thesayyn developed & shared with me that uses some magic https://github.com/bazel-contrib/rules_oci/pull/827/files#diff-d5abc663790cccd8ba4052bec28e9b61492fb27d67fd274b3657202039be1673. I've also got a much simpler approach return ctx.configuration.host_path_separator == ";" but thesayyn suggests that this will not handle RBE cross compilation.

Appreciate your thoughts on how to move forwards with both of these items

[fmeum]

The suggestion by @thesayyn works as it inspects the target platform after an exec transition, which gives you the exec platform used by the transition. You don't need the noop action and DefaultInfo/OutputGroupInfo bit though, you can just define a provider() and return a bool in a field.

If you also want the correct shell path, you could use a rule similar to is_exec_platform_windows that declares the toolchain dependency on the rules_shell toolchain and forwards the path via a provider in the same way.