Flip --experimental_strict_action_env on by default.

See bazelbuild#2574. For a while, many actions did not respect the --action_env command line option, but those have been fixed now. So, I think it's time to flip on this flag for greater hermeticity by default.

RELNOTES: The --experimental_strict_action_env option 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. --noexperimental_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, --noexperimental_strict_action_env will eventually be deprecated and removed.

compile.sh

@@ -93,6 +93,7 @@ log "Building output/bazel"
 # We set host and target platform directly since the defaults in @bazel_tools
 # have not yet been generated.
 bazel_build "src:bazel_nojdk${EXE_EXT}" \
+ --action_env=PATH \
  --host_platform=@bazel_tools//platforms:host_platform \
  --platforms=@bazel_tools//platforms:target_platform \
  || fail "Could not build Bazel"

site/docs/remote-caching.md

@@ -333,12 +333,6 @@ You can pass a user-specific path to the `--disk_cache` flag using the `~` alias
 when enabling the disk cache for all developers of a project via the project's
 checked in `.bazelrc` file.
 
-To enable cache hits across different workspaces, use the following flag:
-
-```
-build --experimental_strict_action_env
-```
-
 ## Known issues
 
 **Input file modification during a build**
@@ -353,15 +347,14 @@ build.
 
 **Environment variables leaking into an action**
 
-An action definition contains environment variables. This can be a problem
-for sharing remote cache hits across machines. For example, environments
-with different `$PATH` variables won't share cache hits. You can specify
-`--experimental_strict_action_env` to ensure that that's not the case and
-that only environment variables explicitly whitelisted via `--action_env`
-are included in an action definition. Bazel's Debian/Ubuntu package used
-to install `/etc/bazel.bazelrc` with a whitelist of environment variables
-including `$PATH`. If you are getting fewer cache hits than expected, check
-that your environment doesn't have an old `/etc/bazel.bazelrc` file.
+An action definition contains environment variables. This can be a problem for
+sharing remote cache hits across machines. For example, environments with
+different `$PATH` variables won't share cache hits. Only environment variables
+explicitly whitelisted via `--action_env` are included in an action
+definition. Bazel's Debian/Ubuntu package used to install `/etc/bazel.bazelrc`
+with a whitelist of environment variables including `$PATH`. If you are getting
+fewer cache hits than expected, check that your environment doesn't have an old
+`/etc/bazel.bazelrc` file.
 
 
 **Bazel does not track tools outside a workspace**

src/main/java/com/google/devtools/build/lib/bazel/rules/BazelRuleClassProvider.java

@@ -111,7 +111,7 @@ public class BazelRuleClassProvider {
  public static class StrictActionEnvOptions extends FragmentOptions {
  @Option(
  name = "experimental_strict_action_env",
- defaultValue = "false",
+ defaultValue = "true",
  documentationCategory = OptionDocumentationCategory.UNCATEGORIZED,
  effectTags = {OptionEffectTag.LOADING_AND_ANALYSIS},
  help =

src/test/py/bazel/windows_remote_test.py

@@ -33,7 +33,6 @@ def _RunRemoteBazel(self, args, env_remove=None, env_add=None):
  '--define=EXECUTOR=remote',
  '--remote_executor=localhost:' + str(self._worker_port),
  '--remote_cache=localhost:' + str(self._worker_port),
- '--experimental_strict_action_env=true',
  '--remote_timeout=3600',
  '--auth_enabled=false',
  '--remote_accept_cached=false',

src/test/shell/bazel/bazel_rules_test.sh

@@ -287,29 +287,19 @@ EOF
  local new_tmpdir="$(mktemp -d "${TEST_TMPDIR}/newfancytmpdirXXXXXX")"
  [ -d "${new_tmpdir}" ] || \
  fail "Could not create new temporary directory ${new_tmpdir}"
- export PATH="$PATH_TO_BAZEL_WRAPPER:/bin:/usr/bin:/random/path"
  if is_windows; then
+ export PATH="$PATH_TO_BAZEL_WRAPPER;/bin;/usr/bin;/random/path;${old_path}"
  local old_tmpdir="${TMP:-}"
  export TMP="${new_tmpdir}"
  else
+ export PATH="$PATH_TO_BAZEL_WRAPPER:/bin:/usr/bin:/random/path"
  local old_tmpdir="${TMPDIR:-}"
  export TMPDIR="${new_tmpdir}"
  fi
- # shut down to force reload of the environment
- bazel shutdown
- bazel build //pkg:test --spawn_strategy=standalone \
+ bazel build //pkg:test --spawn_strategy=standalone --action_env=PATH \
  || fail "Failed to build //pkg:test"
  if is_windows; then
- # As of 2018-07-10, Bazel on Windows sets the PATH to
- # "/usr/bin:/bin:" + $PATH of the Bazel server process.
- #
- # MSYS appears to convert path entries in PATH to Windows style when running
- # a native Windows process such as Bazel, but "cygpath -w /bin" returns
- # MSYS_ROOT + "\usr\bin".
- # The point is, the PATH will be quite different from what we expect on
- # Linux. Therefore only assert that the PATH contains
- # "$PATH_TO_BAZEL_WRAPPER" and "/random/path", ignore the rest.
- local -r EXPECTED_PATH=".*:$PATH_TO_BAZEL_WRAPPER:.*:/random/path"
+ local -r EXPECTED_PATH="$PATH_TO_BAZEL_WRAPPER:.*/random/path"
  # new_tmpdir is based on $TEST_TMPDIR which is not Unix-style -- convert it.
  local -r EXPECTED_TMP="$(cygpath -u "$new_tmpdir")"
  else