Repository: go-task/task

Issue #436: Declared env vars do not take precedence over existing env vars
Created: 2021-01-27T21:04:21Z
Task version: 3.2.2
Operating System: macOS

Example Taskfile showing the issue
version: "3"

env:
  DUMMY: "foo"

tasks:
  default:
    cmds:
      - echo "DUMMY=${DUMMY}"
Example Behavior
$ task -s
DUMMY=foo
$ env DUMMY=placeholder task -s
DUMMY=placeholder

Expectation
$ env DUMMY=placeholder task -s
DUMMY=foo

Outputs the value declared in the Taskfile.
Value declared in env is used for tasks irregardless to existing values. This used to work in a previous version, not sure where it stopped.

Duplicate issue #483: Inconsistent behavior when passing vars from CLI in different ways
Created: 2021-05-03T11:48:03Z
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.

Closing comment (2021-05-03T11:50:27Z): Probably, a duplicate of #436, I'm not sure.
UPD: unlikely, I have the latest release.