feat: add task-level dotenv support

[pd93]

This PR adds support for the task-level dotenv key - A much requested feature.

The key works much the same as it does at a global level:

version: '3'

tasks:
  default:
    dotenv: ['.env']
    cmds:
      - echo "$FOO"

It also supports filenames as variables (like the global key):

version: '3'

tasks:
  default:
    vars:
      ENV: .env
    dotenv: ['{{.ENV}}']
    cmds:
      - echo "$FOO"

• Global env and dotfile variables will be overridden by task-level dotfile variables.
• Task-level dotfile variables will be overridden by task-level env variables.

[pd93]

This is a note-to-self more than anything. I've just spotted ErrIncludedTaskfilesCantHaveDotenvs. I need to look into why this restriction exists and whether we need to add something for task-level dotenv

task/taskfile/read/taskfile.go

Lines 124 to 126 in a160baa

	if v >= 3.0 && len(includedTaskfile.Dotenv) > 0 {
	return ErrIncludedTaskfilesCantHaveDotenvs
	}

[nxtcoder17]

any ETA on when this will come into a release ?

[pd93]

I've just spotted ErrIncludedTaskfilesCantHaveDotenvs. I need to look into why this restriction exists and whether we need to add something for task-level dotenv

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

any ETA on when this will come into a release ?

@nxtcoder17 No ETA. It's still a WIP. It will be released once its ready and another maintainer has time to review it.

[andreynering]

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

[andreynering]

I mentioned this on another PR IIRC, but I'd revert this style change as it's not common IMO

Suggested change

	"enum": [ "none", "checksum", "timestamp" ],
	"enum": ["none", "checksum", "timestamp"],

[pd93]

Whoops. I'm not doing this on purpose, I swear 🤣

[andreynering]

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:

1. I believe you can revert your changes in this validation here and keep the way it works on master
2. 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.

[pd93]

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?

[andreynering]

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! 🙂