Open DjinNO opened 1 year ago
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
I am running into this problem too. I'm not sure what a clean way is to have config be different for different environments. I like @tuwid 's approach, and it is what I wanted to do too, but doesn't seem to work still.
I am also encountering this problem. Until this is resolved, I am running my tasks on Windows using the following command:
$env:ENV='dev' ; task set-context
Can this https://github.com/go-task/task/pull/1627 get merged? Running into the same issue
dotenv file .env:
VAR=test
Taskfile.yml:
Result:
nothing
With global dotenv works good
Task version: master Operating System: Arch Linux