Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vars don't get properly propagated with two levels of included nesting #996

Closed
gsantoro opened this issue Jan 30, 2023 · 2 comments · Fixed by #1256
Closed

Vars don't get properly propagated with two levels of included nesting #996

gsantoro opened this issue Jan 30, 2023 · 2 comments · Fixed by #1256

Comments

@gsantoro
Copy link

Hello,
thanks for the amazing tool that Taskfile is. I have a bit of advanced use case, so bear with me.

I am facing an issue with the current setup:

  • I have three Taskfiles: A, B, C
  • A includes B and calls B:up
  • B includes C and calls C:up
  • C has a variable that I want to be overridable: C_VARIABLE: '{{.C_VARIABLE | default "localhost"}}'

this is the content of A.Taskfile.yml:

version: '3'

includes:
  B: 
    taskfile: ./B.TaskFile.yml

tasks:
  up:
    cmds:
      - task: B:up

this is the content of B.Taskfile.yml:

version: '3'

vars:
  B_VARIABLE: b

includes:
  C: 
    taskfile: ./C.TaskFile.yml
    vars:
      C_VARIABLE: "{{.B_VARIABLE}}"

tasks:
  up:
    cmds:
      - echo "B_VARIABLE {{.B_VARIABLE}}"
      - task: C:up

and this is the content of C.Taskfile.yml

version: '3'

vars:
  C_VARIABLE: '{{.C_VARIABLE | default "localhost"}}'

tasks:
  up:
    cmds:
      - echo "C_VARIABLE {{.C_VARIABLE}}"

If I run the following command it behaves as expected. Meaning that when B:up calls C:up, it overrides the variable C_VARIABLE with the content of B_variable=b

➜ t -t B.Taskfile.yml up
task: [up] echo "B_VARIABLE b"
B_VARIABLE b
task: [C:up] echo "C_VARIABLE b"
C_VARIABLE b

if instead I run the same up task from A

➜ t -t A.Taskfile.yml up
task: [B:up] echo "B_VARIABLE b"
B_VARIABLE b
task: [B:C:up] echo "C_VARIABLE localhost"
C_VARIABLE localhost

the C_VARIABLE is not overridden but it uses the default value instead.

This is not what I was expecting

➜ t -t A.Taskfile.yml up
task: [B:up] echo "B_VARIABLE b"
B_VARIABLE b
task: [B:C:up] echo "C_VARIABLE b"
C_VARIABLE b

Am I doing something wrong? Do I have wrong expectations or is this a bug?

  • Task version: v3.20.0
  • Operating System: MacOS arm64 architecture
@task-bot task-bot added the state: needs triage Waiting to be triaged by a maintainer. label Jan 30, 2023
@acls
Copy link

acls commented Jun 12, 2023

I have the same issue, which I reduced to the following three task files:

# ./Taskfile.yml
version: '3'

includes:
  foo:
    taskfile: ./foo/Taskfile.yml



# ./foo/Taskfile.yml
version: '3'

includes:
  bar:
    vars:
      N: '3'
      PREFIX: 'prefix-'
    taskfile: ./Taskfile.include.yml



# ./foo/Taskfile.include.yml
version: '3'

vars:
  N: '{{.N | default "1"}}'

env:
  N_ENV: '{{.N}}'

tasks:
  baz:
    cmds:
      - echo N {{.N}}
      - echo PREFIX {{.PREFIX}}

When running from the top level, the specified variables aren't used:

$> task foo:bar:baz
task: [foo:bar:baz] echo N 1
N 1
task: [foo:bar:baz] echo PREFIX 
PREFIX

But when running from the second level, they are used:

$> cd foo
$> task bar:baz
task: [bar:baz] echo N 3
N 3
task: [bar:baz] echo PREFIX prefix-
PREFIX prefix-

@ygt-mikekchar
Copy link

This looks like a straight up bug to me. I've not played with this code at all, but assuming I could find some spare time, does this look like something that is unlikely to break other behaviour if fixed? Fixing this would really simplify some of our taskfiles so I'm keen to take a look at it (again assuming my mythical "free time" can be organised).

@andreynering andreynering linked a pull request Jul 8, 2023 that will close this issue
@andreynering andreynering added type: bug Something not working as intended. and removed state: needs triage Waiting to be triaged by a maintainer. labels Jul 8, 2023
@pd93 pd93 removed the type: bug Something not working as intended. label Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants