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
tasks:
'*:*':
vars:
JOB_TYPE: {ref: index .MATCH 0}OPTION: {ref: index .MATCH 1}cmd: <some logic to generate the command with JOB_TYPE and OPTION>'*':
vars:
JOB_TYPE: {ref: index .MATCH 0}cmd:
task: '{{.JOB_TYPE}}:default_option'
If I run task some_job:some_opt, it will throw an error:
task: Failed to run task "some_job:some_opt": task: Found multiple tasks (*:*, *) that match "some_job:some_opt"
Essentially, by using '*', I want to match things that does not contain a : instead of matching everything. I don't think this is possible under current taskfile's mechanism.
I need to do this since both some_job and some_opt are dynamic in my case. I can't statically list all the available choices. Even if I can, there will be too many of them, which requires a lot of boilerplate tasks. A worse thing is that the list might be dynamically updating. One possible choice is to override vars: task JOB_TYPE=some_job OPTION=some_opt, but this makes the syntax too cumbersome and almost defies the purpose of using task.
Is it possible to add a top-level option, for example use_first_wildcard_match: true, to allow this behavior?
The text was updated successfully, but these errors were encountered:
It would be nice to actually be able to use RegExp instead of just a * (which really stands for .+ in RegExp terms.
Maybe add this as an experiment? Or maybe make a different enough syntax so it break the least amount of existing taskfiles - like some-task:/\d+/? I am not sure how slashes behave in YAML, tho, so RegExp wildcards would need to have their task names surrounded by a YAML string definition ("').
@DerpgonCz regex wildcards have been discussed before. We decided not to implement them since the complexity of the feature outweighed the benefit. If you can provide a concrete proposal and use-case for this then we could take another look, but I think this beyond the scope of this issue.
@DerpgonCz regex wildcards have been discussed before. We decided not to implement them since the complexity of the feature did not outweigh the benefit. If you can provide a concrete proposal and use-case for this then we could take another look, but I think this beyond the scope of this issue.
I see, I did not know it was discussed before. Understandably, it would not be a simple task to achieve and would require some planning and writing down the use-cases. I have some stuff in mind, but, unarguably, most of actual use-cases can be achieved via regular arguments.
Consider this case:
If I run
task some_job:some_opt
, it will throw an error:Essentially, by using '*', I want to match things that does not contain a
:
instead of matching everything. I don't think this is possible under current taskfile's mechanism.I need to do this since both
some_job
andsome_opt
are dynamic in my case. I can't statically list all the available choices. Even if I can, there will be too many of them, which requires a lot of boilerplate tasks. A worse thing is that the list might be dynamically updating. One possible choice is to override vars:task JOB_TYPE=some_job OPTION=some_opt
, but this makes the syntax too cumbersome and almost defies the purpose of using task.Is it possible to add a top-level option, for example
use_first_wildcard_match: true
, to allow this behavior?The text was updated successfully, but these errors were encountered: