Feature Request: Set runtime env vars for tests

[sebastianv1]

Test targets can use the env attribute to supply environment variables for tests at runtime; however, these variables are not propagated when running the test target in BwB.

One potential solution is creating an env attribute on custom schemes for the test action similar to what we've done with the launch_action attributes. This would allow us to share the env var dict in the BUILD file with the test target and custom scheme.

Tasks

• [x] #940
• [x] #942
• [x] Fix Expand Variables Based On setting when specifying test env vars/args
  • [x] #951
  • [x] #956
• [ ] Propagate env variables from XXX_unit_test. (Request)

[brentleyjones]

Ideally the env and --test_env will automatically be filled in autogenerated schemes. For Custom schemes maybe we can automatically fill in --test_env, but regardless we should allow specifying them, yes.

[tinder-maxwellelliott]

I am not seeing a ios_unit_tests automatically created schemes containing the target's env variables. I think we need to fix this for auto creation

[cgrindel]

I am not seeing a ios_unit_tests automatically created schemes containing the target's env variables. I think we need to fix this for auto creation

@tinder-maxwellelliott Just to confirm. You would like to see values from this env attribute propagated to automatic schemes? Propagating to automatic schemes seems very reasonable.

What do we want to do about custom schemes? Propagating to custom schemes could be useful, but could be confusing, as well. Perhaps, we should add an attribute to xcode_schemes.test_action() that dictates whether env variables should be propagated. If we do that, then propagating for automatic schemes would be a no-brainer. We would just need to set the argument.

[tinder-maxwellelliott]

What do we want to do about custom schemes? Propagating to custom schemes could be useful, but could be confusing, as well

I feel that out of the box its intuitive if iOS_unit_test's env is automatically applied, custom schemes would be used to override those default values.

[mattdornfeld]

Is there an estimate for when this feature request might be completed? It would be very nice to not have to manually set env vars in XCode to get tests to pass :)

[brentleyjones]

Which part are you still needing? Values set via env attribute on the rule, passed in with --test_env, both, or other?

There is some background work happening on this, but we can probably bump the priority. cc: @maxwellE.

[maxwellE]

I will put some effort on this next week. We would like to also avoid having to specify these env vars in 2 places

[mattdornfeld]

@brentleyjones is it currently possible to propagate the env map definition from an ios_application or a ios_unit_test Bazel target to the Xcode target generated by the xcodeproj rule? I just tested to see if it worked using the latest version of rules_xcodeproj, and the Xcode target env vars were not populated.

[brentleyjones]

It is not currently possible, but that's one way that we want to support soon.

[mattdornfeld]

Okay thank you! Appreciate the info. I'll keep track of progress in this thread.

[brentleyjones]

@mattdornfeld Can you confirm if the latest main has your desired functionally?

[rasberik]

Is there way to pass Argument Passed On Launch via ios_unit_test same way as env?
e.g. pass "-parameter value" or "-AppleLanguages (es)"

[brentleyjones]

How would you do that with ios_unit_test and bazel test today? Once we know that, we can see how to get that picked up by rules_xcodeproj.

[rasberik]

@brentleyjones Thanks for quick reply! For bazel test I can do this args = ["--command_line_args=-AppleLanguages,(es)"], and it picks it up.

[brentleyjones]

:+1: So it looks like we should be able to support that. Can you make a new Feature Request with these details? Thanks!