Open 73 opened 4 years ago
You can obtain something similar by explicitly listing the tasks you want to run, either as a dependency (will run in parallel) or as a sequence of tasks.
I guessed as much. I was looking for a shorter way. Thank you, anyway!
Hi @73 (is it really possible to have 2-chars GitHub usernames? 😄)
That's not currently possible, unless by the way @marco-m described.
Mind sharing more about your use case?
My biggest concern about that is that we don't know in which order we should run these tasks. Even if we use the declaration order, if the user move tasks around this would change the order and it'd be confusing. Also, what about included Taskfiles?
Hi @andreynering,
yes, it is a tow-digit handle. :wink:
I am scripting some data analysis: data -> figures -> report
So I have used namespaces data
, fig
and a build job. When I change something deep down, everything should change. Now, I could mention every figure in the report
job. But I would like to build them all, anyway. So something like fig:*
would be nice. I do not care about the order.
What about included Taskfiles? I don't get the question. Can you explain?
What about included Taskfiles? I don't get the question. Can you explain?
I was referring to the order of tasks itself.
I think that it'd be fine to support this if the documentation says the order is random.
I don't care about the order. I am looking for a short handle that allows me not to specify every job (that I could even mess up) but run all jobs with a common prefix.
@andreynering if this is implemented, maybe it makes sense to take the same approach as Go took for map key traversal, namely enforcing a random order, so that nobody starts relying on a perceived order...
I'd like to expand on this idea a bit more... I've been thinking it could be useful to have Task
interpret glob-like patterns when finding tasks to run by name. https://github.com/gobwas/glob
Basic use case:
includes:
- project1: "./project1/Taskfile.yml"
- project2: "./project2/Taskfile.yml"
tasks:
setup:
- task: "*:setup"
Where setup
runs all included setup tasks such as project1:setup
and project2:setup
Or just run all included setup tasks from the command line
task *:setup
Having the ability to just use a wildcard pattern could reduce the amount of code in a task definition and ease the maintenance burden on Taskfiles that oversee many projects. If I know all of my project Taskfiles are going to define their own setup
task, it makes sense to use a wildcard pattern here instead of always adding the included taskfile's tasks explicitly.
Edit: I guess this could also be achieved external from Task by grepping the available task list and filtering using globs in bash
@andreynering if this is implemented, maybe it makes sense to take the same approach as Go took for map key traversal, namely enforcing a random order, so that nobody starts relying on a perceived order...
A random order would not be great. Though I could see a lexicographic ordering working out well. It would allow tasks to be run in a deterministic order. Similar to how init()
functions are run in Go.
https://yourbasic.org/golang/package-init-function-main-execution-order/
Is it possible to run multiple tasks? Maybe something like:
task figues/*
?