Add arguments parameter to testing.TestEnvironment
#16076
Comments
|
This would be very useful. Just let me add that |
|
Is |
|
Yes, other than |
|
I've tried to implement this feature but it seems to require quite a bit of plumbing and I think (as someone who has zero familiarity with the Bazel code base) would require hand holding or would need to defer to someone more familiar. It's easy enough to locate and update For maintainers and experienced contributors, I'd very much like to see this implemented. |
|
@UebelAndre I'll be busy next week, but feel free to ping me the week after and I can give you some pointers and/or pair. |
|
@fmeum sorry for the delay. Seems you've run into this issue too? |
|
Yes, resolving it is required to allow for generic transition wrappers around tests, which is something I'm interested in. |
|
So how should it be implemented? Do you have bandwidth to work on this? |
|
I think I could work on it, but we should first figure out how we want the new
@comius @UebelAndre I would be very interested in your opinions on this. |
|
I think this sounds good. This provider though wouldn't have any impact on actions though, right? |
|
Yes, this is only about |
|
Any word from @comius on this? Do I understand correctly that progress is blocked on gaining consensus for the design? |
|
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. |
Executable Starlark rules can use the new `arguments` parameter on `RunEnvironmentInfo` to specify the arguments that Bazel should pass on the command line with `test` or `run`. If set to a non-`None` value, this parameter overrides the value of the `args` attribute that is implicitly defined for all rules. This allows Starlark rules to implement their own version of this attribute which isn't bound to its proprietary processing (data label expansion and tokenization). Along the way, this commit adds test coverage and documentation for the interplay between `RunEnvironmentInfo`'s `environment` and `--test_env`. The value of the `arguments` field of `RunEnvironmentInfo` is intentionally not exposed to Starlark yet: It is not clear how these arguments should be represented and whether rules relying on the magic `args` attribute should also provide this field. Fixes bazelbuild#16076 Work towards bazelbuild#12313
Executable Starlark rules can use the new `arguments` parameter on `RunEnvironmentInfo` to specify the arguments that Bazel should pass on the command line with `test` or `run`. If set to a non-`None` value, this parameter overrides the value of the `args` attribute that is implicitly defined for all rules. This allows Starlark rules to implement their own version of this attribute which isn't bound to its proprietary processing (data label expansion and tokenization). Along the way, this commit adds test coverage and documentation for the interplay between `RunEnvironmentInfo`'s `environment` and `--test_env`. The value of the `arguments` field of `RunEnvironmentInfo` is intentionally not exposed to Starlark yet: It is not clear how these arguments should be represented and whether rules relying on the magic `args` attribute should also provide this field. Fixes bazelbuild#16076 Work towards bazelbuild#12313
Executable Starlark rules can use the new `arguments` parameter on `RunEnvironmentInfo` to specify the arguments that Bazel should pass on the command line with `test` or `run`. If set to a non-`None` value, this parameter overrides the value of the `args` attribute that is implicitly defined for all rules. This allows Starlark rules to implement their own version of this attribute which isn't bound to its proprietary processing (data label expansion and tokenization). Along the way, this commit adds test coverage and documentation for the interplay between `RunEnvironmentInfo`'s `environment` and `--test_env`. The value of the `arguments` field of `RunEnvironmentInfo` is intentionally not exposed to Starlark yet: It is not clear how these arguments should be represented and whether rules relying on the magic `args` attribute should also provide this field. RELNOTES: Executable starlark rules can use the `arguments` parameter of `RunEnvironmentInfo` to specify their command-line arguments with `bazel run` and `bazel test`. Fixes bazelbuild#16076 Work towards bazelbuild#12313
|
@UebelAndre I just submitted #16430, which implements Note that the argument takes in a list of strings rather than an |
I'm not sure what you mean by this. Looking at the PR it seems like you added the ability to set |
You can obtain the |
|
I see, that sounds totally reasonable to me! Thank you so much for working on this! |
brandjon
added
team-Rules-API
|
This continues to be a seemingly unnecessary pain point for my team. Being able to generate arguments for a test binary in a rule would save a ton of boilerplate code we need to explain to others all the time. I would very much appreciate if something could be done to support this. |
comius
added
the
P4
This change introduces the `action_args` crate which is something I feel
I keep writing in various repos now. It's original design is to make it
easier to pass args to built binaries. E.g.
```rust
use action_args;
use clap::Parser;
use runfiles::{rlocation, Runfiles};
#[command(version, about, long_about = None)]
struct ClapArgs {}
fn main() {
let args = {
let runfiles = Runfiles::create().unwrap();
let var = std::env::var("ARGS_FILE").unwrap();
let runfile = rlocation!(runfiles, var).unwrap();
let text = std::fs::read_to_string(runfile).unwrap();
let argv = action_args::parse_args(text);
ClapArgs::parse_from(std::env::args().take(1).chain(argv))
};
// ...
// ...
// ...
}
```
This utility will likely be unnecessary should
bazelbuild/bazel#16076 ever be implemented.
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
This change introduces the `action_args` crate which is something I feel
I keep writing in various repos now. It's original design is to make it
easier to pass args to built binaries. E.g.
```rust
use action_args;
use clap::Parser;
use runfiles::{rlocation, Runfiles};
#[command(version, about, long_about = None)]
struct ClapArgs {}
fn main() {
let args = {
let runfiles = Runfiles::create().unwrap();
let var = std::env::var("ARGS_FILE").unwrap();
let runfile = rlocation!(runfiles, var).unwrap();
let text = std::fs::read_to_string(runfile).unwrap();
let argv = action_args::parse_args(text);
ClapArgs::parse_from(std::env::args().take(1).chain(argv))
};
// ...
// ...
// ...
}
```
This utility will likely be unnecessary should
bazelbuild/bazel#16076 ever be implemented.
Co-authored-by: Daniel Wagner-Hall <dawagner@gmail.com>
|
Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale. |
github-actions
bot
added
the
stale
|
This is still desired. |
github-actions
bot
removed
the
stale
Description of the feature request:
I would like to write rules which contain an
argsattribute 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 someargumentsfield 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 releasereturnsdevelopment versionor(@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
The text was updated successfully, but these errors were encountered: