Need some way to substitute envvars into env maps

[peakschris]

Firstly, after some years with bazel I have just come across this repo from a stackoverflow comment. Really cool stuff, it was just what we were missing. Thanks!

It would be really helpful if there was a way to substitute existing envvars (passed via bazel --test_env could be substituted into the itest env maps. This is now the only reason that we need to run batch scripts before running bazel test. For example:

env = { "PATH": "$(PATH);/extra" "TEST_DATA" = "$(ROOT)/subdir" }

It would be further cool if there was a way to provide a canned substitution that pointed to the workspace root.

Thanks!

Chris

[dzbarsky]

Glad to hear this is solving some problems for you!

Could you provide some more details on your use case? It sounds like you are doing something non-hermetic and want an escape hatch?

For example, I don't understand the TEST_DATA example or the desire for a substitution that points to the workspace root? Why not use runfiles or location expansion? For example:

itest_service(
    name = "svc",
    env = {
        "TEST_DATA": "$(execpath :testdata)",
    },
)

filegroup(
    name = "testdata",
    srcs = [ .. ],
)

[peakschris]

Exactly, we are migrating from a legacy build system to bazel, and in the interim whilst both build systems are active, we need to set some envvars to subdirectories of the workspace root for consistency with the existing code. Eventually we won't need this if we manage to achieve the transition! We have such a large amount of stuff to migrate, and we need to take it in steps.

[peakschris]

One more detailed example that I've recently got working with rules_idata:

Test and Service are both started with a common TEST_DATA envvar. The test process reads a file from TEST_DATA and makes a rest call to Service including a relative pathname. Service reads from this relative pathname and returns a response. It's tricky with runfiles and bazel to have both Test and Service starting with a common TEST_DATA directory.

This is horrible, I'd want to see it refactored, but there are perhaps 2000 of these cases, and we need to first just make them work by running them with almost exactly the same environment as they were written to assume (e.g. TEST_DATA pointing to a subdirectory of workspace)

[dzbarsky]

I am guessing the 2000 refers to the # of tests, not the # of services? Perhaps it would work to write sh_binary wrappers around the service binaries that can set up the environment you want? And wrap the tests in a macro or inject env setup code into them in another way?

Another option would be to apply a patch to the env setup in rules_itest to customize things as you want, perhaps after the runfiles env setup

I'm hesitant to add additional complexity to the ruleset to support non-hermetic cases if it means better-behaved setups need to incur the cost as well. We can leave this issue open and see if other users also request a similar feature