Add `arguments` parameter to `testing.TestEnvironment`

Description of the feature request:

I would like to write rules which contain an args attribute where users can define a test with unique command line arguments. I think it would make the most sense to expand testing.TestEnvironment to support some arguments field where users can provide a list of arguments (or, stretch goal, an Args object) to describe arguments to be passed to the test when it starts.

What underlying problem are you trying to solve with this feature?

To accomplish this I’m constantly needing to have my tests execute a platform specific bash/batch script that has the arguments hard coded into it but this has an unfortunate drawback that I can no longer use –run_under on the actual test binary. Over all, the complexity needed to solve for this feel unjustified and that instead, I should be able to describe in a provider some arguments to pass to my test.

Which operating system are you running Bazel on?

Linux, MacOS, Windows

What is the output of bazel info release?

release 5.2.0

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What’s the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[fmeum]

I’m not sure what you mean by this. Looking at the PR it seems like you added the ability to set arguments in starlark rules. Are you saying I’m not able to read that parameter from existing rules? An example being I have foo_binary which returns RunEnvironmentInfo(arguments=["foo"]) as a dependency of bar_binary which tries to index the RunEnvironmentInfo provider and read arguments. This is what’s not exposed?

You can obtain the RunEnvironmentInfo provider instance and e.g. forward it, but you (with this PR) can’t get the arguments out of it. Making that possible would require more thought - I don’t want to propose an API that lends itself to memory regressions by e.g. encouraging recursive list building.

[fmeum]

In my experience, it’s usually easier to gain consensus for a PR than on issue comments. Given that these questions probably don’t warrant a design doc yet, I will look into turning my comment from above into code.