fix: dynamic var uses wrong dir

[kjasn]

The shell command value which stored using the command as a cache key may have collisions with the same command
but different dir. When the command value is related with dir, it will get a wrong command value.

Close #2928

• I have read and followed the Contribution Guide

I used AI assistant to inspect the repo structure and help with tests.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[trulede]

This reminds me of #524 where a solution is presented sh: 'task --offline env # {{now}}'. There is a reason its this way, I think that in global vars you can get the same sh constantly evaluating (undesirable).

What I mean is, probably, the cause of the problem is not: "var uses the wrong dir".

Looking at this PR makes me wonder if the hash of a Task could be used as par of the index:

type dynamicCacheKey struct {
	hash string
	sh  string
}

for global vars the hash would be "", which is probably OK. Imports would need something too. I don't think dir is going to be robust in all situations, however it seems like a good idea regardless.

[kjasn]

This reminds me of #524 where a solution is presented sh: 'task --offline env # {{now}}'. There is a reason its this way, I think that in global vars you can get the same sh constantly evaluating (undesirable).

What I mean is, probably, the cause of the problem is not: "var uses the wrong dir".

Looking at this PR makes me wonder if the hash of a Task could be used as par of the index:

type dynamicCacheKey struct {
	hash string
	sh  string
}

for global vars the hash would be "", which is probably OK. Imports would need something too. I don't think dir is going to be robust in all situations, however it seems like a good idea regardless.

I found it doesn't work for some situation like this: the same task run with different dirs when its dir is templated from var

tasks:
  default:
    cmds:
      - task: build
        vars: { PROJECT: dir1 }
      - task: build
        vars: { PROJECT: dir2 }

  build:
    dir: "{{.PROJECT}}"
    vars:
      HERE:
        sh: pwd
    cmds:
      - echo "{{.HERE}}"
      - echo "{{.PROJECT}}"

Expecte dir1 and dir2, but actual both aredir1 if dynamicCacheKey holds hash.

[ikshantshukla123]

This reminds me of #524 where a solution is presented sh: 'task --offline env # {{now}}'. There is a reason its this way, I think that in global vars you can get the same sh constantly evaluating (undesirable).
What I mean is, probably, the cause of the problem is not: "var uses the wrong dir".
Looking at this PR makes me wonder if the hash of a Task could be used as par of the index:

type dynamicCacheKey struct {
	hash string
	sh  string
}

for global vars the hash would be "", which is probably OK. Imports would need something too. I don't think dir is going to be robust in all situations, however it seems like a good idea regardless.

I found it doesn't work for some situation like this: the same task run with different dirs when its dir is templated from var

tasks:
  default:
    cmds:
      - task: build
        vars: { PROJECT: dir1 }
      - task: build
        vars: { PROJECT: dir2 }

  build:
    dir: "{{.PROJECT}}"
    vars:
      HERE:
        sh: pwd
    cmds:
      - echo "{{.HERE}}"
      - echo "{{.PROJECT}}"

Expecte dir1 and dir2, but actual both aredir1 if dynamicCacheKey holds hash.

thats true