Open apgrucza opened 1 year ago
@apgrucza This doesn't solve your problem per se, but you could take a look at the problem/solution in #920 to see if the scenario described there could work for you. You may find that it helps to reduce the number of Taskfiles that you need to include in your project too. However, this probably isn't practical if the Taskfiles in your subdirectories are very specific (i.e. cannot be generalised).
Thanks for the suggestion @pd93. In my case the Taskfiles in the subdirectories are indeed very specific and so cannot be generalised.
I could of course move all tasks into the root and have just a single Taskfile, but I prefer the separation of concerns that my current structure provides.
Yep, that's understandable. Just thought I'd see if there was a solution that could work for you in the meantime.
Also, see this related PR and comment where this topic has come up before: https://github.com/go-task/task/pull/904#discussion_r1020762235
Regarding this comment from #904:
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.
I didn’t show it in my example above, but I also have a common Taskfile that’s included from all other Taskfiles. The common Taskfile defines shared variables, some of which need to be based on content from .env files. So scoping dotenv to individual Taskfiles would not work for me.
I am running into the same organizational question, see below:
.
├── .env
├── .taskfiles
│ ├── folder-a
│ │ └── Taskfile.yml
│ │ └── .env-2
│ └── folder-b
│ └── Taskfile.yml
├── subprj
│ ├── folder-c
│ │ └── Taskfile.yml
│ │ └── .env-3
│ └── folder-d
│ └── Taskfile.yml
└── Taskfile.yml
What are the recommended guidelines for including task files? I've slightly altered the example to clarify my question. Consider a directory named .taskfiles, designed to store common task routines for inclusion in other task files. According to this ticket, it seems these task files should not contain environment variable inclusions. Is that interpretation correct?
My goal is to execute tasks both from the project's root and within subdirectories, such as sub-prj/folder-c. Moreover, I want to ensure that a task file in folder-c can incorporate common task modules from the .taskfiles directory. This is permissible, right?
However, I encounter a problem when attempting to "include" a task file from folder-c into the root task file. Perhaps this action should not be an inclusion but rather a direct invocation?
Currently the
dotenv
key cannot be used inside included Taskfiles. Doing so gives the following error:Suppose I have the below structure, where the root Taskfile
includes
the Taskfiles in the subdirectories:I find it useful to be able to have the choice to run Task from either:
task app:build
, orapp
subdirectory, e.g.task build
I can't do this and also make use of the
dotenv
feature. If I placedotenv
in the root Taskfile, it will be ignored in case 2. If I placedotenv
in the included Taskfile, I get an error in case 1. I'd likedotenv
declarations in included files to be processed without error. If the same.env
file is referenced in multiple included Taskfiles, this should also not produce an error.This does raise a question about order of precedence when different
.env
files are specified across different Taskfiles. Perhaps we could have a rule whereby values in a.env
file override values from an included.env
file. Or if it's simpler, just return an error if different Taskfiles reference different.env
files.