Environment variables not overriding vars

[boosh]

Thanks for your bug report!

Before submitting this issue, please make sure the same problem was
not already reported by someone else.

Please describe the bug you're facing. Consider pasting example
Taskfiles showing how to reproduce the problem.

• Task version: v3.23.0
• Operating System: Mac Ventura 13.2.1
• Bash: GNU bash, version 5.2.15(1)-release (x86_64-apple-darwin22.1.0)

I don't think this is a dupe of #843 or #993. I just upgraded to 3.23.0 after seeing this issue in 3.19.0. See the following, the first fails to set the variable from the environment, the second works:

version: '3'

vars:
  VARS:

tasks:
  hello:
    cmds:
      - echo "using vars {{.VARS}}"

$ VARS=vars/accounts/example/dev/ task hello
task: [hello] echo "using vars file "
using vars file 

$ task hello VARS=vars/accounts/example/dev/ 
task: [hello] echo "using vars file vars/accounts/example/dev/"
using vars file vars/accounts/example/dev/

[deepbrook]

I don't think this is a bug?

Vars are not environment variables within task. It's true that you can delegate them, and the way to do this is indeed misleading - but you have to do so explicitly:

vars:
  VARS: "{{  .VARS }}"

tasks:
  hello:
    cmds:
      - echo "using vars {{.VARS}}"

Or, since it's a env variable already, this should work as well:

tasks:
  hello:
    cmds:
      - echo "using vars $VARS"

From what I understand, vars is a dict of values available to templating using go's templating engine. Environment variables given via CLI are merged into the command's shell automatically and are available via direct env ref ($var_name), but not automatically in go templating.

So, if you set vars: {VARS: } you're essentially making VARS value null.

It's especially confusing because at the vars level, I believe env variables are available:

vars:
  VARS: "{{  .VARS }}"

It would probably be less confusing if it were scoped under {{ .env.VARS }} or similar.

[trulede]

In the first case, vars overrides the provided env, and resolves to "".
In the second case, the CLI provided vars overrides the var, and resolves to the path (as expected).

This is correct operation. There is also this experiment, and this PR #2288, touch on similar topics.