Calling parent task with templating bug

[ameergituser]

• Task version: v3.39.2
• Operating system: Ubuntu 24.04.1 LTS
• Experiments enabled: No

Use case

A child task (included taskfile task) which can either call its task or a parent task. The behavior is determined based on a variable using template conditional logic.

Example Taskfiles

.
├── child
│   └── Taskfile.yml
└── Taskfile.yml

Child Taskfile

# https://taskfile.dev

version: '3'

tasks:
  hello:
    cmds:
      - task: work
      - task: :work
      - task: '{{if .CALL_PARENT_TASK}}:work{{else}}work{{end}}'


  work:
    cmds:
      - echo "hello from child!"

Parent Taskfile

# https://taskfile.dev

version: '3'

includes:
  child:
    taskfile: ./child/Taskfile.yml
    dir: ./child
    internal: true

tasks:
  test1:
    cmds:
      - task: child:hello


  test2:
    cmds:
      - task: child:hello
        vars: {CALL_PARENT_TASK: true}


  work:
    cmds:
      - echo "hello from parent!"

Output

Running the parent Taskfile task test1 always works as expected:

task test1
task: [child:work] echo "hello from child!"
hello from child!
task: [work] echo "hello from parent!"
hello from parent!
task: [child:work] echo "hello from child!"
hello from child!

However, running the parent task task test2 always fails:

task test2
task: [child:work] echo "hello from child!"
hello from child!
task: [work] echo "hello from parent!"
hello from parent!
task: Failed to run task "test2": task: Task "child::work" does not exist

It seems that the templating has an effect on calling parent tasks.

[vmaerten]

Indeed this syntax is not compatible with templating. As workaround you can do this :

# https://taskfile.dev

version: '3'

tasks:
  hello:
    cmds:
      - task: '{{if .CALL_PARENT_TASK}}parent_work{{else}}work{{end}}'

  parent_work:
    cmds:
      - task: :work
  work:
    cmds:
      - echo "hello from child!"

[ameergituser]

@vmaerten Thanks. Yes i am using that workaround in the meantime.

[vmaerten]

I'm closing this because it's unlikely we will modify it, and we have a workaround.

[ameergituser]

@vmaerten i don't think just closing this is adding any value. I have some questions:

1. Why is it unlikely to be modified/fixed?
2. If there is a valid reason for keeping the current behavior (which feels like a bug to me), then at least, should the documentation not be updated to help the next person encountering this issue?

Just because there is a workaround, it does not mean we can sweep the issue under the rug. It will pop up again.