Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dotenv not working at task level #997

Open
DjinNO opened this issue Feb 1, 2023 · 17 comments · May be fixed by #1627
Open

dotenv not working at task level #997

DjinNO opened this issue Feb 1, 2023 · 17 comments · May be fixed by #1627
Labels
area: env Changes related to environment variables.

Comments

@DjinNO
Copy link

DjinNO commented Feb 1, 2023

dotenv file .env:
VAR=test

Taskfile.yml:

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

Result:
nothing

With global dotenv works good

Task version: master
Operating System: Arch Linux

@task-bot task-bot added the state: needs triage Waiting to be triaged by a maintainer. label Feb 1, 2023
@pd93
Copy link
Member

pd93 commented Feb 13, 2023

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.

@DjinNO
Copy link
Author

DjinNO commented Feb 13, 2023

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

@endorama
Copy link

endorama commented Mar 1, 2023

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.

@pd93
Copy link
Member

pd93 commented Mar 1, 2023

@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.

@pd93 pd93 added the state: awaiting response Waiting for issue author to respond. label Mar 2, 2023
@pd93
Copy link
Member

pd93 commented Mar 10, 2023

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

@pd93 pd93 closed this as not planned Won't fix, can't repro, duplicate, stale Mar 10, 2023
@task-bot task-bot removed the state: needs triage Waiting to be triaged by a maintainer. label Mar 10, 2023
@pd93 pd93 added state: can't repro Not enough information was given to reproduce the issue described. and removed state: awaiting response Waiting for issue author to respond. labels Mar 10, 2023
@MattiasMartens
Copy link

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.

@c-s-w
Copy link

c-s-w commented Dec 6, 2023

@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.

@pd93
Copy link
Member

pd93 commented Dec 6, 2023

@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.

@c-s-w
Copy link

c-s-w commented Dec 6, 2023

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

@pd93 pd93 reopened this Dec 6, 2023
@pd93 pd93 added type: bug Something not working as intended. area: env Changes related to environment variables. and removed state: can't repro Not enough information was given to reproduce the issue described. labels Dec 6, 2023
@pd93
Copy link
Member

pd93 commented Dec 6, 2023

@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.

@c-s-w
Copy link

c-s-w commented Dec 6, 2023

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

@andreynering
Copy link
Member

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

@MattiasMartens
Copy link

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

@tuwid
Copy link

tuwid commented Apr 11, 2024

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

@aminya aminya linked a pull request Apr 28, 2024 that will close this issue
@aminya
Copy link
Contributor

aminya commented Apr 28, 2024

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

@russellboley-uipath
Copy link

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.

@dmitry-mightydevops
Copy link

Can this #1627 get merged? Running into the same issue

@pd93 pd93 removed the type: bug Something not working as intended. label Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: env Changes related to environment variables.
Projects
None yet
Development

Successfully merging a pull request may close this issue.