You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
$ 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/
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:
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.
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.
Activity
deepbrook commentedon Jun 9, 2023
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:
Or, since it's a env variable already, this should work as well:
From what I understand,
varsis 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 makingVARSvalue null.It's especially confusing because at the
varslevel, I believe env variables are available:It would probably be less confusing if it were scoped under
{{ .env.VARS }}or similar.trulede commentedon Dec 5, 2025
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.