-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
input? #59
Comments
i've used this tool in the past and found the ability to pass cli args in willy-nilly useful on occasion. hypothetically maybe i want to wrap some npm scripts with |
I like in that example that the inputs are just flags, that's easy to understand I'm not sure about just having a single CLI_ARGS variable tho; it seems like you might want more control in systems with a lot of tasks: if you're building up a task set from many task files spread out over a codebase, I don't think you should have to think about all of the tasks and whether they'll respond the right way to your flag something like
and then
…but that's a lot to type my other train of thought here is kind of inspired by terraform "inputs", where a task can declare some inputs, and you can pass them as flags, but also we render a fun interactive form for any missing inputs |
oh i'm a big fan of that tf-esque idea. love setting defaults and overriding later as needed. ansible does some interesting things along these lines with variables where you can assign values to variables in a number of places (in a task / play / playbook, at cli, env vars, vars file...) and then at execution time the value is chosen based on a heirarchy, (ie cli args will always override any other assignments, definitions in vars.yml will always be overridden, etc.) |
i think this might not be the best solution, since some programs use different (albeit inferior) styles of flags (go programs come to mind) separately but also related to inputs, i would love to be able to set environment variables for tasks |
probably more than half of my "cmd"s are multiline scripts, so I don't think a solution without some kind of explicit templating is viable |
Tasks can't take any input. Not flags, not stdin, not nothin else besides. One dogfoody use case for this would be a tag-and-release script for Run, which would require specifying a version identifier somehow.
"not run's purview" is a reasonable answer.
"tasks can declare structured inputs, which the UI can handle appropriately" might be a fun answer
The text was updated successfully, but these errors were encountered: