Dynamic variable execution environment does not inherit globally set environment variables

[kerma]

It may be as designed, but it's been bugging me for a while and creates quite a bit of confusion. So if nothing else, I'll document the behavior here.

See the following example:

version: '3'
env:
  NAME: "giselle"
tasks:
  default:
    vars: 
      person:
        sh: echo $NAME
    cmds:
      - echo "Hello $NAME"
      - echo "Hello {{ .person }}"
    silent: true

Output:

Hello giselle
Hello

That makes dynamic variables a bit useless in places where you need to pass auth or other relevant info via env.

[andreynering]

Hi @kerma,

Good catch! I think it makes sense to fix this and make it consistent.

It may not be extremely easy, though. The variables pipeline is a separate process than the actual execution.

[kerma]

I'll do some investigation myself to figure out the complexity of it.

[megakoresh]

This issue seems to have been abandoned but the inconsistent behavior is still there. Can this be given higher priority? What's the situation with complexity, @kerma ?

Additionally, when working around this with a environment variable defaults, it does not work at the taskfile level, only inside the task:

version: 3

env:
  ENV: '{{default "dev" .ENV}}'
  STACK_NAME: '{{default "development" .STACK_NAME}}'

vars:
  COMPONENT_NAME:
    sh: if [[ {{.ENV}} == "prod" ]]; then echo com.company.ProductionComponent; else echo {{.ENV}}.{{.STACK_NAME}}.DevelopmentComponent; fi

tasks:
  debug:
    cmds:
      - echo {{.ENV}}
      - echo {{.STACK_NAME}}
      - echo {{.COMPONENT_NAME}}

Will produce:

$ task debug ENV=prod STACK_NAME=production
task: [debug] echo prod
prod
task: [debug] echo production
production
task: [debug] echo dev.development.DevelopmentComponent
dev.development.DevelopmentComponent

Moving the COMPONENT_NAME variable declaration to task level OR moving it to env section and referencing it as an environment variable ($COMPONENT_NAME) fixes the issue. But this also looks like a related bug to me. If not, I can open a separate issue about it.

[TheAceMan]

This looks like a similar issue to #1742 which has a PR for a potential fix.