--action_env=ENVVAR is not picked up

[erenon]

Description of the problem

--action_env=ENVVAR is not propagated to the rules, while --action_env=ENVVAR=foobar is.

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

$ cat env/env.bzl
def _env_impl(ctx):
  print(ctx.configuration.default_shell_env)

env = rule(implementation=_env_impl)

$ cat env/BUILD
load('//env:env.bzl', 'env')

env(name = 'print_env')

$ export FOO=bar
$ echo $FOO
bar
$ bazel build //env:print_env --action_env=FOO 
DEBUG: /home/erenon/bazel/hello/env/env.bzl:3:3: {}
$ bazel build //env:print_env --action_env=FOO=baz
INFO: Build option --action_env has changed, discarding analysis cache.
DEBUG: /home/erenon/bazel/hello/env/env.bzl:3:3: {"FOO": "baz"}

In the first invocation, I expected {"FOO": "bar"}, taken from the invocation environment, as specified by https://docs.bazel.build/versions/2.1.0/command-line-reference.html#flag--action_env .

What operating system are you running Bazel on?

$ uname -r
4.15.0-91-generic

What's the output of bazel info release?

release 3.1.0

Have you found anything relevant by searching the web?

Lot of similar bugs, but not exactly this.

[alanfalloon]

One thing to check. Do you have a tools/bazel wrapper script in your repo? If so, does it update the environment before spawning $BAZEL_REAL?

[erenon]

@alanfalloon : I have no such script. The above is reproducible as-is.

[jmmv]

Huh, the interesting thing is that the environment variables do get passed properly. Given:

genrule(name = "env", outs = ["env.out"], cmd = "env | grep FOO | tee $@")

we see that the value is passed correctly to the action:

$ FOO=bar bazel build //env --action_env=FOO
INFO: Analyzed target //env:env (1 packages loaded, 1 target configured).
INFO: Found 1 target...
INFO: From Executing genrule //env:env:
FOO=bar
Target //env:env up-to-date:
  bazel-bin/env/env.out
INFO: Elapsed time: 0.137s, Critical Path: 0.04s
INFO: 1 process: 1 darwin-sandbox.
INFO: Build completed successfully, 2 total actions

$ FOO=baz bazel build //env --action_env=FOO
INFO: Analyzed target //env:env (0 packages loaded, 0 targets configured).
INFO: Found 1 target...
INFO: From Executing genrule //env:env:
FOO=baz
Target //env:env up-to-date:
  bazel-bin/env/env.out
INFO: Elapsed time: 0.172s, Critical Path: 0.03s
INFO: 1 process: 1 darwin-sandbox.
INFO: Build completed successfully, 2 total actions

So I'm guessing this is a problem in the Starlark object passed to the rules and not actually with environment variable propagation.

[jmmv]

Actually this sounds like #4912, which contains a diagnosis of this issue.