Automated rollback of commit f7f1a8f756f33f86b1bdc5023d5052117b62523e.

*** Reason for rollback ***

Updated to avoid https://github.com/bazelbuild/bazel/issues/3501

This is a rollback of a rollback, with additional
modifications to BazelConfiguration.java to fix
https://github.com/bazelbuild/bazel/issues/3501,
the issue that was the reason we rolled back the
original change.

The additional updates serve to propagate the
client's TMP and TEMP envvars to the action, which
is a short-term solution to allow actions have a
TMP/TEMP envvar on Windows. They need at least one
of those to create temp directories.

The long-term solution is to set a value for TMP
or TEMP in the executor just before executing the
actions, so the TMP/TEMP would not be part of the
action key.

All of this only affects Bazel on Windows.

*** Original change description ***

Automated rollback of commit 0abf5fa2d64c76def5a8fa0f960b73ce0566af4d.

*** Reason for rollback ***

Breaks Bazel CI (https://github.com/bazelbuild/bazel/issues/3501)

*** Original change description ***

Android BusyBox: actions use the default shell env

SpawnActions that run the Android BusyBox now use
the default shell environment.

This has the following benefits:
- Bazel propagates the PATH, TMPDIR envvars to the
  action
- Bazel propagates the --action_env envvars to the
  action

This allows the Bazel client to pass
--action_env=TMP or --action_env=TEMP (whichever
of the envvars is defined) to the server, so the
BusyBox actions will have TMP/TEMP set (to the
same value as the clientenv), so they can create
temp directories using
java.nio.file.Files.createTempDirectory.

This method seems to be calling the GetTempPath
WinAPI function, which needs the TMP or TEMP
envvar, otherwise it falls back to returning
c:\windows which is non-writable.

There's one drawback of using the default shell
environment, although @ulfjack is working on it:
- PATH is now also part of the action's cache key.
  However in a single-machine environment (no
  remote execution) and assuming PATH isn't likely
  to change between builds, this probably doesn't
  poision the action cache in practice.

This change is a short-term solution. Propagating
the client env's TMP/TEMP means we make that part
of the action's cache key.

The ideal long-term solution will be to not
propagate this envvar, and instead let the
execution strategy set it to some
client-env-independent value.

See https://github.com/bazelbuild/bazel/issues/3264

Change-Id: I756a4203b5d86c881bc36cc089e35cde0d419914

RELNOTES: none
PiperOrigin-RevId: 164696600

1 files changed, 1 insertions, 0 deletions

diff --git a/src/main/java/com/google/devtools/build/lib/rules/android/ResourceShrinkerActionBuilder.java b/src/main/java/com/google/devtools/build/lib/rules/android/ResourceShrinkerActionBuilder.java
index 4fc305f8d1..33436cd110 100644
--- a/src/main/java/com/google/devtools/build/lib/rules/android/ResourceShrinkerActionBuilder.java
+++ b/src/main/java/com/google/devtools/build/lib/rules/android/ResourceShrinkerActionBuilder.java
@@ -225,6 +225,7 @@ public class ResourceShrinkerActionBuilder {
 
     ruleContext.registerAction(
         spawnActionBuilder
+            .useDefaultShellEnvironment()
             .addTool(sdk.getAapt())
             .addInputs(inputs.build())
             .addOutputs(outputs.build())