- Task version:
v3.4.2 (h1:DRATD5qavWC5FqpopJ/JcCelOMakFtGS7CubdZ/FiQY=)
- Operating System:
Linux ... 5.4.0-70-generic #78-Ubuntu SMP ... x86_64 x86_64 x86_64 GNU/Linux
The issue description
The documentation implies that passing variables into task as env vars and as arguments has the same effect:
Since some shells don’t support above syntax to set environment variables (Windows) tasks also accepts a similar style when not in the beginning of the command.
However, this is not true. See the example and explanation below.
Example Taskfile showing the issue
version: "3"
vars:
V: original_v
env:
EV: "{{.V}}"
E: original_e
tasks:
example:
cmds:
- echo "env EV is $EV"
- echo "env E is $E"
- echo "var V is {{.V}}"
- echo "var EV is {{.EV}}"
- echo "var E is {{.E}}"The example
Running without args:
$ task example -s
env EV is original_v
env E is original_e
var V is original_v
var EV is
var E is original_e
This shows the first issue: env is not expanded when used as var ({{.EV}}).
Running with env vars:
$ V=new_v task example -s
env EV is original_v
env E is original_e
var V is original_v
var EV is new_v
var E is original_e
The var was re-defined in env when executed as var ({{.EV}}) but it has the original value for V itself. The documentation says, env vars have the lowest priority, so the latter is expected.
Running with arguments:
task example -s V=new_v
env EV is new_v
env E is original_e
var V is new_v
var EV is
var E is original_e
Here, using env as var is not expanded as it was in the default execution. However, the explicitly passed value of var is successfully re-defined and substituted when executing the var.
The fix
First of all, executing env vars (env) as regular variables (vars) gives unexpected results. I think it should either match to the value they produce when called as env vars (so $EV and {{.EV}} is always the same), or using them as vars should be explicitly forbidden (since it's not documented anyway).
Secondly, there is a mismatch between passing the var as env var and as a CLI argument. I think the easiest fix is to document the behavior, adding "Variables passed as CLI arguments" before "Global variables" in the list "Task will look for the below".
Another solution for the latter is to prefer "Environment variables" over "Global variables". In that case, the behavior should match. I think it would make more sense since global variables are usually the defaults for the tasks, so explicitly specified variables from the CLI should re-define it. This one is breaking change, though.
v3.4.2 (h1:DRATD5qavWC5FqpopJ/JcCelOMakFtGS7CubdZ/FiQY=)Linux ... 5.4.0-70-generic #78-Ubuntu SMP ... x86_64 x86_64 x86_64 GNU/LinuxThe issue description
The documentation implies that passing variables into
taskas env vars and as arguments has the same effect:However, this is not true. See the example and explanation below.
Example Taskfile showing the issue
The example
Running without args:
This shows the first issue:
envis not expanded when used asvar({{.EV}}).Running with env vars:
The
varwas re-defined inenvwhen executed asvar({{.EV}}) but it has the original value forVitself. The documentation says, env vars have the lowest priority, so the latter is expected.Running with arguments:
Here, using
envasvaris not expanded as it was in the default execution. However, the explicitly passed value ofvaris successfully re-defined and substituted when executing the var.The fix
First of all, executing env vars (
env) as regular variables (vars) gives unexpected results. I think it should either match to the value they produce when called as env vars (so$EVand{{.EV}}is always the same), or using them asvarsshould be explicitly forbidden (since it's not documented anyway).Secondly, there is a mismatch between passing the
varas env var and as a CLI argument. I think the easiest fix is to document the behavior, adding "Variables passed as CLI arguments" before "Global variables" in the list "Task will look for the below".Another solution for the latter is to prefer "Environment variables" over "Global variables". In that case, the behavior should match. I think it would make more sense since global variables are usually the defaults for the tasks, so explicitly specified variables from the CLI should re-define it. This one is breaking change, though.