Wildcards don't work with vars specified in task includes

[robak86]

Description

Given this config file:

version: '3'

includes:
  'stack:*':
    taskfile: ./Taskfile.stack.yml
    vars:
      ENV: '{{index .MATCH 0}}'

the app raises the following error:

template: :1:2: executing "" at <index .MATCH 0>: error calling index: index of untyped nil

The matching using index .MATCH 0 works inside the included Taskfile.stack.yml, but since the configuration allows passing vars for the included task files, would it be possible to support index .MATCH in the includes vars section as well? That enables a clean approach where included tasks don't have to know how to extract the variables.

Version

3.49.1

Operating system

MacOS 15.7.4

Experiments Enabled

No response

Example Taskfile

[trulede]

I don't quite understand what you want to achieve. Perhaps a before/after example to clarify?

[robak86]

Sorry for the unclear description. I could have been more precise.

The goal is to run tasks like task stack:production:deploy or task stack:staging:deploy, where the matched environment name (production, staging, …) is passed as a variable into the included taskfile.

Current workaround (works, but leaks an implementation detail):

Taskfile.yml:

version: '3'

includes:
  'stack:*':
    taskfile: ./Taskfile.stack.yml

Taskfile.stack.yml:

version: '3'

tasks:
  deploy:
    cmds:
      - echo "Deploying to {{index .MATCH 0}}"

The included taskfile has to use index .MATCH 0 directly — it needs to know it was included via a wildcard and which capture group to read.

---

Desired approach (not currently working):

Taskfile.yml:

version: '3'

includes:
  'stack:*':
    taskfile: ./Taskfile.stack.yml
    vars:
      ENV: '{{index .MATCH 0}}'

Taskfile.stack.yml:

version: '3'

tasks:
  deploy:
    cmds:
      - echo "Deploying to {{.ENV}}"

The included taskfile just uses a plain {{.ENV}} variable — it doesn't need to know anything about wildcards or .MATCH. The extraction is done at the includes level, where it conceptually belongs.

Currently this fails with index of untyped nil because .MATCH isn't available when the vars block under includes is evaluated. The request is to make .MATCH available in that context, the same way it already is inside the included taskfile itself.

[trulede]

@robak86 you want to run a task from a set of tasks, where the set of tasks is selected (imported) by an ENVAR. This is to allow easy switching between modes of operation (e.g. staging / production).

There is a way to do this already:

version: '3'

includes:
  build: ./Taskfile_{{OS}}.yml

would that work for you? (replace OS with REL, then set an cmd: $ REL=prod task deploy).

[robak86]

Not exactly, I'd just like to be able to capture the wildcard value at the moment when I include a task. So it's about having this syntax work correctly:

includes:
  'stack:*':
    taskfile: ./Taskfile.stack.yml
    vars:
      ENV: '{{index .MATCH 0}}'

Currently it raises template: :1:2: executing "" at <index .MATCH 0>: error calling index: index of untyped nil, which forces moving the capture logic into the included taskfile — less clean than passing the captured value as a var from the parent. The point is to decouple child task from parent, so it doesn't have to know about wildcards or capture groups, but just specifies contract via variables. Hope that makes it clearer.

[trulede]

But you can define your task in the included file with a wildcard and handle the MATCH values in that task. I think that makes more sense to keep the things together? Than to couple them to the import mechanism ... even if it were possible.

[robak86]

Yes, but then the task isn't reusable when I want to parametrise it with a wildcard capture in one place and call it with a fixed value in another. I noticed there's an experiment for remote Taskfiles (#1317), so I assume reusability is important factor here. Having the parent decide how variables are constructed and passing them down gives a cleaner contract than the child imposing a specific wildcard pattern on the parent.