--action_env with defined value is not working as expected

[siberex]

Description of the problem:

According to the docs, --action_env could be used to set name=value pairs:

--action_env=<a 'name=value' assignment with an optional value part>
Specifies the set of environment variables available to actions. Variables can be either specified by name, in which case the value will be taken from the invocation environment, or by the name=value pair which sets the value independent of the invocation environment.

If such values are set either via CLI arguments or via .bazelrc like this:

build --action_env=HELLO=WORLD
run --action_env=HELLO=WORLD
test --test_env=HELLO=WORLD

then only --test_env works as expected and passes env correctly.

--action_env does not pass value to the binary target (checked with Go and JS toolchains, issue is not related to lang rules).

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

Use this repo to reproduce:

https://github.com/siberex/bazel_--action_env

git clone git@github.com:siberex/bazel_--action_env.git /tmp/action_env_test
cd /tmp/action_env_test
bazel run //:go
bazel run //:js --action_env=HELLO=WORLD

--test_env is working:

bazel test //:go_test --test_env=HELLO=WORLD
bazel test //:js_test --test_env=HELLO=WORLD

Note:
Without predefined value it works fine taking env value from invocation environment: HELLO=WORLD bazel run //:js --action_env=HELLO. Issue is related only to name=value syntax.

What operating system are you running Bazel on?

Mac OS 10.14.5

What's the output of bazel info release?

release 0.26.1

Have you found anything relevant by searching the web?

Could not find anything relevant.

[ulfjack]

If you want to set an environment variable for the tool you want to run with "bazel run", then you can just set that environment variable before calling Bazel, like so:

FOO=foo bazel run //bar

The --action_env command line flag is intended to pass environment variables to build actions (--test_env to pass to test actions). We don't consider the binary-to-run as a build action.

Only exception: if you bazel run a test target, it'll also add the environment variables from --action_env and --test_env.

[sluongng]

@ulfjack I think its a bit limited not having a way to predefined the environment variables via Bazel.

One simple use case is export GOPRIVATE=git.company.org to skip Golang checksumdb for private modules. Im sure there are other use cases too.

I really dont want to build a Makefile to invoke my baze run //<target> just to work around this. And I would argue that by providing a way to explicitly define the environment variable, you are increasing the hermetic nature of bazel run

[CesarPantoja]

Note this also affects the ability to set env vars to targets on run configurations on JetBrains based IDEs as you can't set env vars on the run config. So you loose the ability to debug targets that require ENV vars

[cvigo]

Another example of this limitation: OpenAPI generator, that generates source code from API definition (swagger) files. If you want the generated source files to be go-formatted, you must set the environment variable GO_POST_PROCESS_FILE="/usr/local/bin/gofmt -w"

I tried

1. GO_POST_PROCESS_FILE="/usr/local/bin/gofmt -w" bazel build ...
2. bazel build ... --host_action_env=GO_POST_PROCESS_FILE="/usr/local/bin/gofmt -w"
3. bazel build ... --action_env=GO_POST_PROCESS_FILE="/usr/local/bin/gofmt -w"

None of them works... From the OpenAPI generator output:
[main] INFO o.o.c.languages.AbstractGoCodegen - Environment variable GO_POST_PROCESS_FILE not defined so Go code may not be properly formatted. To define it, try export GO_POST_PROCESS_FILE="/usr/local/bin/gofmt -w" (Linux/Mac)

[mr-pascal]

Why was this closed? I don't see any particular fix?

Also is there really no possibility to set an environment variable for the bazel run command in the .bazelrc file? Is pretending the environment variable before every invocation really the only way?

e.g. in my case I building docker images via bazel run ... the repository of the docker image and later the push to the repository (and even later the deployment) should point to a specific GCP project I wanted to define in the `.bazelrc´ file to have it consistent over developer machines..

[sne4ky]

Why is this closed? I'm running bazel in a container and neither the --action_env flag nor prepending the env variables work for me when I do a bazel run.

[loeffel-io]

+1

[Flamefire]

Yes this issue still is there in various variations, see also #17062

[fmeum]

I assume that the reason this is closed is that it is too broad. I parsed at least the following topics out of this thread that probably deserve new, more focused issues if anybody is interested in seeing them resolved:

1. There is no way to configure the environment of bazel run from .bazelrc.
2. The docs for which actions respect --action_env and --host_action_env aren't accurate (they don't mention use_default_shell_env being required, which seems to be the cause of --action_env with defined value is not working as expected #8578 (comment)).
3. --action_env with defined value is not working as expected #8578 (comment), but I don't know what could be causing this.

[Flamefire]

Part of the confusion seems to be the naming: --action_env and --host_action_env

Especially with only the output of bazel build --help (IIRC) it is hard to see that --action_env applies only to target-configurations. Maybe that can be improved by extending on the prefix: --target_action_env, --all_action_env (or no prefix, i.e. --action_env means "all" as documented before) and similar. Of course the reference to use_default_shell_env would be helpful and a good explanation of that and why it isn't the default (maybe it should?), i.e. what the benefits are.

[pramodka-revefi]

+1 to this issue. Not being able to pass in environment variables to the target binary through bazel run is real pain.

Update: My team primarily uses bazel for Java. We used bazel run --jvmopt=-Duser.timezone=UTC as a workaround. Also updated our .bazelrc file with this