Order of template variable evaluation seems wrong

[uristernik]

Description

When running task with environment variables like so WORKSPACE=ZZ DIRECTORY=YY task bla I'd expect the templates to be evaluated before execution which is not what I am seeing

Here is the setup to reproduce and hopefully explains it a bit better:

File structure:
├── Taskfile.yml
├── commands
│   └── Taskfile.yml
└── jobs
    └── Taskfile.yml

Contents of root taskfile:

version: "3"

includes:
  commands:
    taskfile: ./commands/Taskfile.yml
    flatten: true
  jobs:
    taskfile: ./jobs/Taskfile.yml
    flatten: true

contents of commands/taskfile.yml:

version: '3'

tasks:
  base:
    cmds:
      - echo {{.WORKSPACE}}
      - echo {{.DIRECTORY}}

  other-task:
    cmds:
      - echo "Hello World!"

contents of jobs/taskfile.yml:

version: '3'

includes:
  commands:
    taskfile: ../commands
    internal: true

output: prefixed

tasks:
  calling:
    cmds:
      - task: calling-{{.CLI_ARGS}}

  calling-:
    cmds:
      - task: commands:base

  calling-1:
    cmds:
      - task: calling-
        vars:
          DIRECTORY: '{{.DIRECTORY}}-suffix'
          WORKSPACE: '{{.WORKSPACE}}-suffix'
      - task: commands:other-task

When running WORKSPACE=ZZ DIRECTORY=YY task calling -- I get:

task: [commands:base] echo ZZ
[commands:base] ZZ
task: [commands:base] echo YY
[commands:base] YY

When running WORKSPACE=ZZ DIRECTORY=YY task calling -- 1 I get:

task: [commands:base] echo ZZ
[commands:base] ZZ
task: [commands:base] echo YY
[commands:base] YY
task: [commands:other-task] echo "Hello World!"
[commands:other-task] Hello World!

but I expect:

task: [commands:base] echo ZZ-suffix
[commands:base] ZZ-suffix
task: [commands:base] echo YY-suffix
[commands:base] YY-suffix
task: [commands:other-task] echo "Hello World!"
[commands:other-task] Hello World!

I assume that what happens is that the calling task get evaluated and then we can't override the template variables used inside it.

Is that expected? Is there any workaround for that?

I need this pattern to avoid configuring several tasks over and over again, what I want to achieve is:

generic-task

specific-task:

• generic-task

another-specific-task:

• generic-task with slightly different vars
• generic-task

Version

v3.42.1

Operating system

Darwin / arm64

Experiments Enabled

No

Example Taskfile

described above

[uristernik]

Playing a bit more I am realizing the template variables are evaluated in when the file is parsed, not when you call the task.
This limits the ability to modular task definitions

[uristernik]

@andreynering any chance having an 👁 here?

[trulede]

@uristernik if you try this, it will work.

version: '3'

includes:
  commands:
    taskfile: ../commands
    internal: true

output: prefixed

tasks:
  calling:
    cmds:
      - task: calling-{{.CLI_ARGS}}

  calling-:
    cmds:
      - task: commands:base
        vars:
          DIRECTORY: '{{.DIRECTORY}}' 
          WORKSPACE: '{{.WORKSPACE}}'

  calling-1:
    cmds:
      - task: calling-
        vars:
          DIRECTORY: '{{.DIRECTORY}}-suffix'
          WORKSPACE: '{{.WORKSPACE}}-suffix'
      - task: commands:other-task

There are a few issues already open on this kind of topic. I think the scenario is more complex than it initially seems ...

[uristernik]

Sorry for the late reply, and thank you! This solution worked for me.

On a related note, I found the inheritance and precedence logic for environment and task variables to be a bit unintuitive. The system seems to rely heavily on fallback mechanisms, which wasn't immediately obvious. It might be beneficial to clarify this behavior further in the documentation.

Appreciate your help!