Repository navigation
computed vars in dotenv paths #2826
Description
Description
When a dotenv path references a variable computed via sh, the template renders incorrectly — the variable appears empty, causing the resolved path to fall back to the task's working directory.
Expected behavior
{{.DOTENV}} resolves to the output of mktemp and the dotenv file at that path is loaded.
Actual behavior
{{.DOTENV}} renders to an empty string. The empty path is resolved against the task's working directory.
$ task
task: Failed to read env file ...: read /home/user/project: is a directoryRelated issues
- Dynamic .env file #434 — variable interpolation in dotenv: paths (implemented for static vars only)
- Updated Environment Variables Before Dotenv File #1912 — CLI-provided vars not visible in dotenv: paths (includes a sh: mktemp example; closed pointing to PR Fix handling of CLI provided global vars. #2288, which was not merged)
- {{.USER_WORKING_DIR}} evaluated after dotenv #1312 — {{.USER_WORKING_DIR}} not available in global dotenv: paths (closed with workarounds only)
Workaround
Avoid dotenv entirely and source the file explicitly in each task that needs it:
cmds:
- |
set -a && source {{.DOTENV}} && set +aVersion
3.48.0
Operating system
Ubuntu 20.04
Experiments Enabled
No response
Example Taskfile
version: '3'
vars:
DOTENV:
sh: mktemp
tasks:
default:
dotenv:
- '{{.DOTENV}}'
cmds:
- echo "AWS_KEY=$AWS_KEY"
Activity
rpf3 commentedon May 7, 2026
If this is unintended, or intended but a possible feature addition, I'd like to assist in fixing/implementing.
trulede commentedon May 7, 2026
In this PR, on the following line, you might be able to expand the path using the templater already created in the function. It should work.
https://github.com/go-task/task/pull/2711/changes#diff-88a1dcc1be6c418f7d053085cf094890a7a3e4f767c4f8500cf51373589e5bb9R89
If it does work (will be one line change I think) make a review with the suggestion. Add a test case too if you what, the PR already covers a few cases, so add yours.
rpf3 commentedon May 7, 2026
@trulede I have a local branch to work on this but my initial testing is failing. I think the block here
is still causing the dotenv
shto fail because the template didn't resolve thedotenvvariable{{.DOTENV}}so it returns the working directory which means it moves on toenvs, err := godotenv.Read(dotEnvPath). We could change your conditional to check ifdotEnvPathis a directory but I think this would be a little hacky. I feel like what's really called for is that if the template can't resolve{{.DOTENV}}, we want to know about it instead of just giving back a valid path.trulede commentedon May 8, 2026
I don't think the sh var will be available (at that point in the processing). You could try and set the value at the cli, at which point the var will be available to the templater.
$ foo=$(mktemp) task sometask
Then its a question if the dotenv paths are also processed by the templater. If not, see my previous suggestion.
rpf3 commentedon May 10, 2026
Running
DOTENV=$(mktemp) taskon my test file resolves the primary issue; but obviously I'd like to be able to just set this in the Taskfile definition itself.Is this in the ballpark of what you were thinking?
If so, I tried to open a PR to your fork branch but I don't think it is open.
trulede commentedon May 19, 2026
I think your commit (especially the test) is a really good example of how to use the capabilities of task to solve a common workflow.