Skip to content
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

Add an option to allow multiple wildcard matches and only run the first match #1688

Open
simonrouse9461 opened this issue Jun 9, 2024 · 4 comments
Labels
area: wildcards Changes related to wildcard matching type: feature A new feature or functionality.

Comments

@simonrouse9461
Copy link

Consider this case:

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?

@task-bot task-bot added the state: needs triage Waiting to be triaged by a maintainer. label Jun 9, 2024
@pd93
Copy link
Member

pd93 commented Jun 9, 2024

This was discussed when adding wildcard support. We can use this issue to track support for this.

@pd93 pd93 added type: feature A new feature or functionality. area: wildcards Changes related to wildcard matching and removed state: needs triage Waiting to be triaged by a maintainer. labels Jun 9, 2024
@DerpgonCz
Copy link

DerpgonCz commented Jul 31, 2024

I will do you one better.

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 ("').

@pd93
Copy link
Member

pd93 commented Jul 31, 2024

@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
Copy link

@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.

I rest my case then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: wildcards Changes related to wildcard matching type: feature A new feature or functionality.
Projects
None yet
Development

No branches or pull requests

4 participants