TASKFILE_DIR with incorrect value

[yz89122]

# /Users/user/includes/Taskfile.yml
version: '3'

envs:
  PROJECT_ROOT: '{{.TASKFILE_DIR}}'

tasks:
  test:
    cmds:
      - cmd: echo '{{.PROJECT_ROOT}}'

# /Users/user/Taskfile.yml
version: '3'

includes:
  included:
    taskfile: 'includes'

output: prefixed

tasks:
  test:
    deps: ['included:test']
    cmds:
     - cmd: echo '{{.PROJECT_ROOT}}'

cd /Users/user && task test

output:

task: [included:test] echo '/Users/user/includes'
[included:test] /Users/user/includes
task: [test] echo '/Users/user'
[test] /Users/user

expected output:

task: [included:test] echo '/Users/user/includes'
[included:test] /Users/user/includes
task: [test] echo '/Users/user/includes'
[test] /Users/user/includes

• Task version: Task version: 3.38.0 ()
• Operating system: macOS
• Experiments enabled: false

[vmaerten]

Hello!
First of all, even if it works because variables are global, it's not recommanded to use variable declared in a children.

Back to your question, it's intended. We load all variables / envs when we read all the Taskfiles in the DAG. Then, each time we run a task (here we run included:test and test) we compile variables / envs , so:

• first run (included:test) we compile PROJECT_ROOT to TASKFILE_DIR (=> '/Users/user/includes')
• second run (test) we we compile PROJECT_ROOT to TASKFILE_DIR (=> '/Users/user/')

Why do we that ? because some variables rely on special variables (TASKFILE_DIR & co) or rely on sh variable which need to be compiled at runtime.

If you want to achieve this, I recommand to declare the variable / env in the Taskfile you want to use it

[yz89122]

Hi, @vmaerten

Thanks, I totally understand how it happened.

IMHO, if it's not recommended to use global variable / env from included taskfile, I'll strongly suggest that do not make the variables / envs from an included taskfile accessible outside of it. This is misleading and easily accidentally referenced it.

Thanks for your answering.