Working directory of included taskfiles differs depending on called task's location

[deepbrook]

Given the following Taskfiles:

# test/Taskfile.yaml
---
version: 3

includes:
  foo:
    taskfile: lib/foo.yaml
    dir: ./

tasks:
  pwd:
    cmds:
      - echo $PWD
  toplevel:foo-bar-pwd:
    cmds:
      - task: foo:bar:pwd

# test/lib/foo.yaml
---
version: 3

includes:
  bar:
    taskfile: ./bar.yaml
    dir: ./

tasks:
  pwd:
    cmds:
      - echo $PWD

  foolevel:bar-pwd:
    cmds:
      - task: bar:root

# test/lib/bar.yaml
---
version: 3
tasks:
  pwd:
    cmds:
      - echo $PWD

We get the following behaviour when calling the above tasks:

🐟 ❯ task pwd
task: [pwd] echo $PWD
/tmp/test

🐟 ❯ task foo:pwd
task: [foo:pwd] echo $PWD
/tmp/test

took 10s
🐟 ❯ task foo:foolevel:bar-pwd
task: [foo:bar:pwd] echo $PWD
/tmp/test/lib

🐟 ❯ task foo:bar:pwd
task: [foo:bar:pwd] echo $PWD
/tmp/test/lib

IMO, this is unexpected behaviour and a bug - as I'm calling all tasks from test/Taskfile.yaml, which specifically declares the exec directory should be ./ for the included taskfiles.

In otherwords, the correct behaviour should be as follows if running foo.yaml in the lib directory:

🐟 ❯ task -t foo.yaml pwd
task: [pwd] echo $PWD
/tmp/test/lib

🐟 ❯ task -t foo.yaml foolevel:bar-pwd
task: [bar:pwd] echo $PWD
/tmp/test/lib

🐟 ❯ task -t foo.yaml bar:pwd
task: [bar:pwd] echo $PWD
/tmp/test/lib

tl;dr: It looks like the value of dir is dependent on the location of task being called within the taskfiles includes tree, instead of being correctly merged/updated with the parent taskfile's dir when recursing into the included files.

Task Version

🐟 ❯ task --version
Task version: v3.17.0 (h1:tDkE4X8VUUSNzFMTQNuEEhR/3cfI9hILLuwm365sNCM=)

[simonrouse9461]

Any update on this?

[ShoGinn]

So this is closest to the problem I'm experiencing.

Including a task file does change the working directory.

It is not a problem since I created a variable for my PROJECT_DIR

  PROJECT_DIR:
    sh: "git rev-parse --show-toplevel"

Here is my example using your examples:

# test/Taskfile.yaml
---
version: 3

vars:
  PROJECT_DIR:
    sh: pwd

includes:
  foo:
    taskfile: lib/foo.yaml
    dir: ./

tasks:
  pwd:
    cmds:
      - echo $PWD
  toplevel:foo-bar-pwd:
    cmds:
      - task: foo:bar:pwd
      - task: foo:bar:pwd:root

# No change to this file
# test/lib/foo.yaml
---
version: 3

includes:
  bar:
    taskfile: ./bar.yaml
    dir: ./

tasks:
  pwd:
    cmds:
      - echo $PWD

  foolevel:bar-pwd:
    cmds:
      - task: bar:root

# test/lib/bar.yaml
---
version: 3
tasks:
  pwd:
    dir: "{{ .PROJECT_DIR }}"
    cmds:
      - echo $PWD
  pwd:root:
    dir: "/{{ .PROJECT_DIR }}"
    cmds:
      - echo $PWD

I just want you to see the bar file where I added explicit directories to the tasks

Notice that the pwd:root has a preceding slash for the directory

{{.PROJECT_DIR}} in this case is dynamically set in the Taskfile.yaml

the output is this

 task toplevel:foo-bar-pwd
task: [foo:bar:pwd] echo $PWD
/task_bug/lib/task_bug
task: [foo:bar:pwd:root] echo $PWD
/task_bug

Not sure why you would need to specify the extra / my guess is they are linked somehow

[ktdasher1]

Impact on Reusable Taskfiles
This issue makes it impossible to write truly reusable Taskfiles. When creating a Taskfile that might be included by others, you have no way of knowing:

How deep in the nesting hierarchy it will be
What dir: value to set to maintain consistent working directory behavior

Case Study

Consider this three-level hierarchy:

root Taskfile.yml:

version: '3'

includes:
  level1:
    taskfile: './level1/Taskfile.yml'

tasks:
  whoami:
    silent: true
    cmds:
      - cmd: echo "Root Taskfile: Current working dir: $(PWD)"
      - task: level1:whoami

level1/Taskfile.yml:

version: '3'

includes:
  level2:
    taskfile: './level2/Taskfile.yml'
    dir: ../  # Required workaround

tasks:
  whoami:
    silent: true
    cmds:
      - cmd: echo "Level1 Taskfile: Current working dir: $(PWD)"
      - task: level2:whoami

level1/level2/Taskfile.yml:

version: '3'

tasks:
  whoami:
    silent: true
    cmds:
      - cmd: echo "Level2 Taskfile: Current working dir: $(PWD)"

Without dir: workarounds (inconsistent behavior):

$ task --taskfile /testinclude/Taskfile.yml whoami
Root Taskfile: Current working dir: /testinclude
Level1 Taskfile: Current working dir: /testinclude
Level2 Taskfile: Current working dir: /testinclude/level1  # ← Changes!

With dir: ../ in level1 (consistent, but requires knowing nesting depth):

$ task --taskfile /testinclude/Taskfile.yml whoami
Root Taskfile: Current working dir: /testinclude
Level1 Taskfile: Current working dir: /testinclude
Level2 Taskfile: Current working dir: /testinclude  # ← Fixed

The Problem
The first-level include (level1) correctly inherits the root's working directory, but second-level and deeper includes (level2) inherit their parent's TASKFILE_DIR instead of the root's working directory. This inconsistency between nesting levels makes it impossible to write portable, reusable Taskfiles without knowing in advance how deeply they will be nested.

[trulede]

I'm working of the code basis of PR #2445 that has a related change, but seems to exhibit the same error.

The problem appears to related to TASK_DIR (Absolute path where the task is executed), which is set from t.Dir, which when includes:dir is not configured is set during taskfile parsing, here:

    if include.AdvancedImport {
	// Save the include.Dir and task.Dir so that the final task.dir can
	// be calculated when the task is compiled (and templating is available).
	task.IncludeDir = include.Dir
	task.IncludeTaskDir = task.Dir
	// If task.dir is not set then use the include.dir.
	if len(task.Dir) == 0 {
		task.Dir = include.Dir  // **** this is the cause.
	}

Its a fairly long strand to untangle. Basically, it seems that if using AdvancedImport (and your example does) then task.Dir should potentially be set to something else.

If, for example, I comment out the line:

if len(task.Dir) == 0 {
//	task.Dir = include.Dir  // ****disable this!
}

then you example works as you expect. Unfortunately it breaks other things ... so more investigation is needed.

Here is the debug I used:

$ task whoami
root Taskfile Current working dir /home/trule/git/task/ISSUES/0903
    ROOT_DIR         = /home/trule/git/task/ISSUES/0903
    TASKFILE         = /home/trule/git/task/ISSUES/0903/Taskfile.yml
    TASKFILE_DIR     = /home/trule/git/task/ISSUES/0903
    TASK_DIR         = /home/trule/git/task/ISSUES/0903
    USER_WORKING_DIR = /home/trule/git/task/ISSUES/0903
Level1 Taskfile Current working dir /home/trule/git/task/ISSUES/0903
    ROOT_DIR         = /home/trule/git/task/ISSUES/0903
    TASKFILE         = /home/trule/git/task/ISSUES/0903/level1/Taskfile.yml
    TASKFILE_DIR     = /home/trule/git/task/ISSUES/0903/level1
    TASK_DIR         = /home/trule/git/task/ISSUES/0903
    USER_WORKING_DIR = /home/trule/git/task/ISSUES/0903
Level2 Taskfile Current working dir /home/trule/git/task/ISSUES/0903/level1
    ROOT_DIR         = /home/trule/git/task/ISSUES/0903
    TASKFILE         = /home/trule/git/task/ISSUES/0903/level1/level2/Taskfile.yml
    TASKFILE_DIR     = /home/trule/git/task/ISSUES/0903/level1/level2
    TASK_DIR         = /home/trule/git/task/ISSUES/0903/level1
    USER_WORKING_DIR = /home/trule/git/task/ISSUES/0903

[trulede]

@deepbrook @ShoGinn @ktdasher1 @andreynering

The cause of the problem is identified:

task/taskfile/node_file.go

Line 86 in 4e963f8

// NOTE: Uses the directory of the entrypoint (Taskfile), not the current working directory

This function is called while reading/merging the tasks and it sets the Include.Dir to the directory of the taskfile, not the working dir (i.e.TASK_DIR).

Based on the documentation, I would suggest this is a bug:

By default, included Taskfile's tasks are run in the current directory, even if the Taskfile is in another directory, but you can force its tasks to run in another directory by using this alternative syntax:

However, imagine all nested include files operating in the same folder ...

Solution?
Leave it as it is, then set include.dir = '{{TASK_DIR}}' for all task files.
Or,
change the behaviour, then if you want included tasks running in a different folder, set include.dir = '{{.TASKFILE_DIR}}'.

IMHO: change the behaviour to match the documentation.

[deepbrook]

The current behavior is counter intuitive imho. I expect the tasks to be run in the dir i called task - if that specific task needs another, perhaps specific directory, it should take of that itself.

So, definitely +1 for fixing the behavior to follow the current docs.

And thank you for looking into this!