You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 18, 2024. It is now read-only.
Some circumstances may involve calling multiple run targets, with only one of them actually needing command line arguments. The current behavior is that all run targets get the arguments passed to them, which makes it so users have to "hack around" the fact that the others should not get the arguments. Ideal interface:
multirun(
name="bar",
commands= [
"cmd_1",
"cmd_2",
],
# when doing `bazel run //foo:bar -- --some --arguments`# only cmd_1 should see `--some --arguments`argument_command="cmd_1",
)
The text was updated successfully, but these errors were encountered:
You could make argument_command a list called invocation_argument_commands:
multirun(
name="bar",
commands= [
"cmd_1",
"cmd_2",
"cmd_3",
],
# when doing `bazel run //foo:bar -- --some --arguments`# only cmd_1 & cmd_3 should see `--some --arguments`invocation_argument_commands=["cmd_1", "cmd_3"]
)
though in practice it feels that only one of the commands will typically be desired as the place to put the args from the actual invocation. Regarding the commands having individual arguments, that seems to be workable if you know the arguments before somebody calls bazel run, but if you want them to be overridable for one (or more) of your commands at invocation time it works less well.
FWIW, my use case is that I want to run a command for pushing a docker image and then execute a script that uses that pushed image. The script is one that people will be running regularly, and wanting to change the arguments at bazel run time.
@augray why not create "intermediary" commands? use command macro to create a command with all the required arguments and then use those "intermediary" commands in multirun?
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Some circumstances may involve calling multiple run targets, with only one of them actually needing command line arguments. The current behavior is that all run targets get the arguments passed to them, which makes it so users have to "hack around" the fact that the others should not get the arguments. Ideal interface:
The text was updated successfully, but these errors were encountered: