I am not able to reproduce this. Also running Arch on master and your example works fine for me:

├── .env
└── Taskfile.yml

# .env
VAR=test

# Taskfile.yml
version: "3"
silent: true
tasks:
  test:
    dotenv: [".env"]
    cmds:
    - echo $VAR

Outputs:

❯ task test                       
test

Are you sure your copy of master is up to date? I would recommend installing a release and trying again.

Interesting. I have go-task-bin-3.20.0-1, tried reinstalling, didn't help. At the same time, in a container with ubuntu - it works

Me and a colleague stumbled upon this issue today. Using the provided example we have been able to reproduce this issue on task v3.15.2 and v3.20.0 but not on v3.21.0.

@endorama That's interesting.. I don't believe there were any changes in v3.21.0 that would effect this, so I'm not sure why you'd be able to repro in v3.20.0, but not latest. Are you able to provide a reproduceable sample for v3.20.0?

Otherwise, I might close this until someone is able to repro again since it isn't currently effecting anyone in the latest release.

Closing this for now. If anyone is able to repro this, please feel free to leave a comment and we can reopen.

I have this exact issue on arm64, taskfile version 3.30.1.

local taskfile:

# https://taskfile.dev

version: "3"

dotenv: [".env"]

tasks:
  default:
    dotenv: [".env"]
    cmds:
      - echo {{.MYVAR}}

Output: "foo". But comment out the top-level dotenv clause and "foo" does not print.

@pd93, I can reproduce this, too. I've tested it with latest build (v3.32.0) on Windows and Ubuntu. Only top-level dotenv is evaluated, on task-level it is ignored. Looking at the strace output, the .env file is even not read when set on the task-level.

@c-s-w. I'm still unable to reproduce this (v3.32.0) on Linux. I used @MattiasMartens's example to test along with the following .env file:

MYVAR=foo

Running task outputs:

task: [default] echo foo
foo

If you can provide a sample Taskfile.yml and .env that repros the issue, then I will reopen.

@pd93 I'm testing it with these files: https://gist.github.com/c-s-w/7ae4e3c9b87e3e3735b05fd2a6aea542

@andreynering What's the expected behaviour here? The docs do not mention that you should be able to use variables defined in a dotenv via the templating engine ({{.MYENVVAR}}) and this is what @c-s-w is saying does not work (I can repro this). Instead, the docs say you should use $MYENVVAR which is what the OP was reporting as not working - This does still work for me.

However, if I move the dotenv declartion in @c-s-w's example to the global level, the variable is available in the templating engine. This seems to be rather inconsistent and confusing.

@pd93 Having the variables available via the templating engine allows the usage of requires, which doesn't work with .e.g. $MYVAR.

@pd93 I'd say that this is a bug. It should be available for templating, yes.

Here is a slightly more verbose repro of what I am now understanding is four different cases.

version: 3

# Un-comment the lines below for file-wide .env
# dotenv:
#   - .env

tasks:
  default:
    dotenv:
      # Task-specific .env
      - .env
    cmds:
      - "echo By template: {{.MY_VAR}}"
      - "echo By env: $MY_VAR"

Output on my machine (arm64, 3.32.0):

By template:
By env: foo

Output with file-wide .env un-commented:

By template: foo
By env: foo

Same issue on mac on version Task version: v3.35.1
with a .env.development and .env.staging
with similar contexts

CLUSTER_NAME=staging
AWS_ACCOUNT_ID=xxxxxxxx
AWS_REGION=eu-north-1

version: '3'

silent: false
dotenv: ["./.env.{{.ENV}}"]

tasks:
  set-context:
    desc: "Set the Kubernetes context based on the environment"
    cmds:
      - echo For env {{.ENV}} we got $AWS_REGION $CLUSTER_NAME $AWS_ACCOUNT_ID
      - "kubectl config use-context arn:aws:eks:$AWS_REGION:$AWS_ACCOUNT_ID:cluster/$CLUSTER_NAME"
      - "echo 'Using context: arn:aws:eks:$AWS_REGION:$AWS_ACCOUNT_ID:cluster/$CLUSTER_NAME for environment: {{.ENV}}'"

getting the following

> task -v ENV=staging set-context
task: "set-context" started
task: [set-context] echo For env staging we got $AWS_REGION $CLUSTER_NAME $AWS_ACCOUNT_ID
For env staging we got

Created a pull-request that fixes this issue: #1627