0.21.0 --incompatible_strict_action_env and unzip [duplicate of #7026]

[excitoon]

Description of the problem / feature request:

https://ci.appveyor.com/project/excitoon/bazel/builds/21227594

0.21.0 stopped discovering unzip though it is in %Path%. 0.20.0 worked fine.

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

PowerShell:

iex (new-object net.webclient).downloadstring('https://get.scoop.sh')
scoop bucket add user https://github.com/excitoon/scoop-user.git
scoop bucket add versions # For Python 2.7
scoop install user/msys2
scoop install user/bazel0.21.0

bazel build //src:bazel

What operating system are you running Bazel on?

Appveyor, any image.

What's the output of bazel info release?

0.21.0

[excitoon]

As I can see it is this feature:

  - The --experimental_strict_action_env option has been renamed to
    --incompatible_strict_action_env and is now on by default. This
    means Bazel will no longer use the client's PATH and
    LD_LIBRARY_PATH environmental variables in the default action
    environment. If the old behavior is desired, pass
    --action_env=PATH and --action_env=LD_LIBRARY_PATH.
    --noincompatible_strict_action_env will also temporarily restore
    the old behavior. However, as --action_env is a more general and
    explicit way to pass client environmental variables into actions,
    --noincompatible_strict_action_env will eventually be deprecated
    and removed. See #6648 for more details.

[excitoon]

I guess even though Bazel don't use %PATH%, it should not break itself.

[RNabel]

This is related to #5265, I believe. We're running into this with our repos as well, so we need to keep --action_env=PATH around in order to acces tools such as unzip or 7z.

[laszlocsomor]

This is a duplicate of #7026.
Please follow that bug.