pipe runnable_binary wrapper output

[matt-sm]

Follow up to 1d8e362.

We are still experiencing intermittent occurances of this issue whereby the wrapper script is empty on windows. Was finally able to repro with a target that had a dep on a large number of runnable binaries. Inexplicably, when I changed the redirect to a pipe, the target never failed. With a redirect I would still see intermittent failures.

Closest msys2 related bug: msys2/MSYS2-packages#1703 (comment)

[matt-sm]

@cerisier this is another PR for your review. We've been running our windows builds with this fix for a while now and haven't seen any more runnable_binary failures

[cerisier]

Can you try with this or the equivalent as the cmd_ps attribute of the genrule ?

(Get-Content "$(location @rules_foreign_cc//foreign_cc/private:runnable_binary_wrapper.sh)") -replace 'EXECUTABLE', "$(rlocationpath {name})" | Set-Content $@

[matt-sm]

The problem with this idea is that private:runnable_binary_wrapper.sh won't run in ps

Fails on first line

line 1: #!/usr/bin/env: No such file or directory

[matt-sm]

During more testing on windows with multiple runnable_binary rules, there was a race condition whereby the contents of tmp were written to the wrong wrapper.

Changing to tmp_$$$$ to make this file unique.

[cerisier]

All of this sound more and more like a sandboxing issue. Do you have the sandbox enabled ? are your actions local only ?

[matt-sm]

On windows there is essentially no sandboxing.

This is reproducible in a test I have that looks like

def create_runnable_binaries(bin_names):
    for bin_name in bin_names:
        runnable_binary(
            name = "run-" + bin_name,
            binary = bin_name,
            foreign_cc_target = ":mytarget",
            visibility = ["//visibility:public"],
        )

where there are 40 different binaries I'm creating tests for. The tmp_$$$$ fixes this.

Even with a unique filename (or $@ directly), the redirect (>) still produced intermittent empty files on Windows.