Up-to-Date Check wrong when executing task in Subdirectory

[deicon]

Description

Problem

I do have a Taskfile with a number of common tasks, which should all be runnable within a mono repo directory structure.

monorepo
├── backend-one
│   ├── src
│   │   └── Main.c
│   └── target
├── backend-two
│   ├── src
│   │   └── Main.c
│   └── target
└── Taskfile.yml

For simplicity here are 2 backends, each having a Main.c. All Main.c Files are of course different and will produce different checksums.

To compile each backend I want to be able to

cd backend-one
task compile

to compile the Main.c and produce a Main.o

version: '3'

tasks:

  clean: 
    dir: "{{ .USER_WORKING_DIR }}"
    cmds:
      - rm -rf target/*
    

  compile:
    dir: "{{ .USER_WORKING_DIR }}"
    sources: 
      - "src/Main.c"
    generates:
      - "target/Main.o"
    cmd: gcc -c src/Main.c -o target/Main.o

Expected

Everytime I run

cd backend-[one|two|three]
task compile

I want the task to be executed, if not up to date.

Current Result

As the .task directory, storing the checksums is created next to the found Taskfile, this will result in wrong up-to-date checks.

tree monorepo
monorepo
├── backend-one
│   ├── src
│   │   └── Main.c
│   └── target
├── backend-two
│   ├── src
│   │   └── Main.c
│   └── target
└── Taskfile.yml

❯ cd monorepo/backend-one
❯ task compile
task: [compile] gcc -c src/Main.c -o target/Main.o
❯ cd ../backend-two
❯ task compile
task: [compile] gcc -c src/Main.c -o target/Main.o

tree -al ../../monorepo
../../monorepo
├── .task
│   └── checksum
│       └── compile
├── backend-one
│   ├── src
│   │   └── Main.c
│   └── target
│       └── Main.o
├── backend-two
│   ├── src
│   │   └── Main.c
│   └── target
│       └── Main.o
└── Taskfile.yml

So the Expected result for calling compile again in either one of the two backend directories would not execute the compile.

Current

But in fact, as the checksums are stored in the Top Level Directory next to the found Taskfile and are using the Tasks Name as Filename, this will execute in one backend folder.

> pwd
/monorepo/backend-two
❯ task compile
task: Task "compile" is up to date
❯ cd ../backend-one
❯ task compile
task: [compile] gcc -c src/Main.c -o target/Main.o

Version

3.44.0

Operating system

Darwin Macos 15.5 (24F74)

Experiments Enabled

No response

Example Taskfile

version: '3'

tasks:

  clean: 
    dir: "{{ .USER_WORKING_DIR }}"
    cmds:
      - rm -rf target/*
    

  compile:
    dir: "{{ .USER_WORKING_DIR }}"
    sources: 
      - "src/Main.c"
    generates:
      - "target/Main.o"
    cmd: gcc -c src/Main.c -o target/Main.o

[deicon]

One Solution could be to use the working dir, where the task is actually running.
So either create a .task directory there and use it in this case, or, as I have done here locally, by prefixing the checksum/compile file with the working directory.

tree -al ../../monorepo
../../monorepo
├── .task
│   ├── checksum
│   │   └── compile
│   └── Users
│       └── noob
│           └── monorepo
│               ├── backend-one
│               │   └── checksum
│               │       └── compile
│               └── backend-two
│                   └── checksum
│                       └── compile
├── backend-one
│   ├── src
│   │   └── Main.c
│   └── target
│       └── Main.o
├── backend-two
│   ├── src
│   │   └── Main.c
│   └── target
│       └── Main.o
└── Taskfile.yml

[trulede]

Using label might work, it changes the task name, also in the checksum file (described here https://taskfile.dev/usage/#prevent-unnecessary-work in one of the info boxes).

version: '3'

tasks:

  clean: 
    dir: "{{ .USER_WORKING_DIR }}"
    cmds:
      - rm -rf target/*
    
  compile:
    label: "{{ .TASK }}-{{ .USER_WORKING_DIR }}"
    dir: "{{ .USER_WORKING_DIR }}"
    sources: 
      - "src/Main.c"
    generates:
      - "target/Main.o"
    cmd: gcc -c src/Main.c -o target/Main.o

[deicon]

This will work for sure but still seems to be a workaround. Forgetting to label a task will lead to this behavior again. It also pollutes and bloats the taskfile.

[trulede]

You can set TASK_TEMP_DIR to get the behaviour you want; and instead polluting and bloating the filesystem 😜 ; a simple command alias would suffice to achieve that. This might be good!

However, as (or if) your taskfile gets more sophisticated; defer and for for parallel compile; you will encounter similar problems again. The same solutions would apply.

[deicon]

As i said that's all a workaround. The taskfile should be self contained and working as intended without changing the internal semantics by setting external variables.
Beeing inside a directory and calling compile should be sufficient. I, as the taskfile provider want my team members to simply use the commands without them needing to know the specifics.

Anyhow, i consider this behavior to be bug and not just confusing.

[trulede]

@deicon Sources/generates is rather flakey IMHO. But many things in Task are that way, and slowly it gets better ... but you see 300+ issues for something not that complicated ... its telling you something.

A while back it used to be necessary to do the label modification to get run to work correctly. That was fixed at some point, I think with a hash on the internal task representation, which picks up all the special vars (like USER_WORKING_DIR). I've done a similar thing for a different reason (#2287).

I think that if the sources/generate would use this "task hash" as the index for the checksums, it would solve your problem rather well. Perhaps if you checkout the the code behind #2287, which is not complex, you could find a way to use the "task hash" as the index behind sources/generates. If you do that, and all the existing tests pass, it's a good sign - these things are complicated.

"task hash" here: https://github.com/go-task/task/pull/2287/files#diff-05ed798798e201a0fe6355799c9adb03b42b72710770a86ddecc4def33773c51R141