Repository navigation
feat: add task-level dotenv support - #904
Conversation
|
any ETA on when this will come into a release ? |
2d9043f to
552802c
Compare
@andreynering I've added 552802c to address this, but I'm still unsure as to what the original decision was to omit dotfiles from included Taskfiles. Is this something that can be revisited now?
@nxtcoder17 No ETA. It's still a WIP. It will be released once its ready and another maintainer has time to review it. |
andreynering
left a comment
There was a problem hiding this comment.
Hi @pd93, thanks for working on this!
I tried to answer your question in a comment below, and I don't think we can undo the changes you made on the validation.
Other than that, if you don't have further questions, you're free to merge this PR to master yourself. 🙂
| "description": "Defines which method is used to check the task is up-to-date. `timestamp` will compare the timestamp of the sources and generates files. `checksum` will check the checksum (You probably want to ignore the .task folder in your .gitignore file). `none` skips any validation and always run the task.", | ||
| "type": "string", | ||
| "enum": ["none", "checksum", "timestamp"], | ||
| "enum": [ "none", "checksum", "timestamp" ], |
There was a problem hiding this comment.
I mentioned this on another PR IIRC, but I'd revert this style change as it's not common IMO
| "enum": [ "none", "checksum", "timestamp" ], | |
| "enum": ["none", "checksum", "timestamp"], |
There was a problem hiding this comment.
Whoops. I'm not doing this on purpose, I swear 🤣
There was a problem hiding this comment.
Hey @pd93,
Regarding your question on this...
I believe that the reason I added this validation at the time was because, if we allowed dotenv on included Taskfiles, this would cause an unintended side-effect how things work today on the code. Basically the env in the included Taskfile would be merged into the main Taskfile. Given that:
- I believe you can revert your changes in this validation here and keep the way it works on master
- In a future PR, we could allow dotenv on included Taskfiles, but that would require a refactor so these env would be scoped in the included Taskfile and not merged into the main Taskfile. In short, dotenv would only affect tasks on its own Taskfile and not all tasks. At least that's how I would expect it to work, but this is open to discussion, and we may want to open an issue about this.
There was a problem hiding this comment.
I suspect I'm misunderstanding slightly, but these sound contradictory to me?
I don't think we can undo the changes you made on the validation
you can revert your changes in this validation here and keep the way it works on master
Could you please clarify for me. Would you like to keep the changes in 4614c77 or revert them?
There was a problem hiding this comment.
Hey @pd93,
Sorry for the confusion.
I meant keep the same behavior as master. Taskfiles with global dotenvs would be problematic (until we refactor to scope them to be valid for tasks in that specific Taskfile only). Tasks with local dotenvs are fine, because they are already scoped by design.
I just reverted your last commit and merged to master. Thanks! 🙂
552802c to
4614c77
Compare

This PR adds support for the task-level
dotenvkey - A much requested feature.The key works much the same as it does at a global level:
It also supports filenames as variables (like the global key):
envanddotfilevariables will be overridden by task-leveldotfilevariables.dotfilevariables will be overridden by task-levelenvvariables.