The full list of taskfile paths that has been evaluated should be visible in `task --list-all --json`

[adamscybot]

Description

It's likely an unspoken but commonplace expectation that taskfiles will only includes other taskfiles that are within the scope of a project directory structure.

Possibly this could turn into a discussion about being able to provide some kind of additional flag to go alongside --dir <path>, or an alternative to it, to enforce this at runtime like --no-parent-includes. But I see this issue as a lower-hanging fruit that enables those who want to go out of their way to enforce a check against unexpected inclusion outside of a project with minimal effort.

One such use case where you really want this is for orchestrating task over untrusted projects, like vscode extensions. I am currently building a task extension for VSCode that is based on the VSCode TaskProvider API. In these cases, it would be nice to warn the user that a project is about to do this.

It also enables such locations to be watched via fs notifications.

If task --list-all --json had a property at the root level (since some included taskfiles may not have any tasks, but the fact it was included remains relevant) which would be an array of all the included paths encountered during task list evaluation, then there would at least be a way to validate this.

It probably has some debug use cases as well as a bonus, especially if constructing paths using template vars.

[andreynering]

@adamscybot Would you like to open a PR for this?

[adamscybot]

Hi @andreynering. Sure! I'm away on vacation soon, but I will see to this when I'm back.

[adamscybot]

@andreynering I just want to briefly discuss the approach before I dig in further, as this touches on some design choices that I don't want to drive against (or maybe I'm overthinking it 😊). It also perhaps interacts with other efforts to increase debuggability.

After getting to grips with the codebase, here is my thought process and potential approaches. Looking for you to correct me or give a shove in the right direction :).

• I'm assuming we'd want to avoid the merged Taskfile holding any reference back to the graph itself just so it can be queried during construction of the JSON, as TaskfileGraph orchestrates the merging logic when Merge is invoked, in order to produce a "final" root taskfile that is reflective of the graphs state at that particular point in time. So opening the graph up for further nonsensical mutation by having it hanging around in any way would be bad. Equally, I'm assuming shoving a reference to the graph onto the Executor would not be a good idea for similar reasons.
• Therefore, I think the URIs need to be captured and stored as values somewhere. That leads to my biggest question -- where? Options:
  1. A somewhat straightforward thing to do is to introduce a SourceLocations list property on the Taskfile, and have the Taskfile.Merge method append the Location of the taskfile to be merged, into this list. Meaning intermediate Taskfiles would also have this "URI stack". Conveniently, the JSON construction code could then simply access it via e.Taskfile.SourceLocations. However, I believe this is not the correct answer, as this information is already known to the orchestrating TaskFileGraph. But perhaps it could make sense as a pattern in wider debuggability contexts in future, e.g. if wanting to be able to report on the provenance of individual vars etc and not just the "location stack", storing some immutable data on the Taskfile that builds up all the way down the merge ops, would be one way of doing it. So this makes me wonder if its still a candidate. This is also an approach that is ultimately a minimal change.
  2. You could just have TaskfileGraph.Merge set this property on the root Taskfile instead, by querying the graph right there, after it's created the root taskfile. Feels a bit gross since it mixes merge-time orchestration with reporting concerns, and is coupling-by-the-backdoor.
  3. Just slap a property on the executor e.g. e.TaskfileSourceLocations and populate it inside readTaskfile in setup.go by querying the graph, which is accessible there. This feels leaky to me as doesn't consider wider traceability/debuggability future. But it would obviously get this particular job done.
  4. Potentially do store some pointer to the graph on the root taskfile, but via some "reporter" facade that only lets it be interrogated for read purposes, and therefore effectively renders it immutable. Possibly a flavour of this approach is -- instead of making this facade accessible on the root taskfile -- change TaskfileGraph.Merge to return a new MergeResolved struct or something that has this facade alongside the root taskfile (then probably put it on an executor property such that it can be accessed downstream to build the JSON or whatever else). You can see how this could be useful in future improved logging/debug mode features.