Wes McNamee

> There's some space for a tool that bundles "how to watch & what to run" This is interesting. I think this is a similar abstraction in fact to running...

> In the most trivial case, I have a task to build assets that's defined in both the [Taskfile](https://github.com/prql/prql/blob/118db1423fd867d70121161c85c7ead5ef38b030/Taskfile.yml) and the [GHA workflow](https://github.com/prql/prql/blob/118db1423fd867d70121161c85c7ead5ef38b030/.github/workflows/test.yaml). (They are slightly different, but that supports...

> I think we could do this by refactoring the type taskfile.Tasks from map[string]*Task into a tree structure that we could then traverse in depth first order. When I get...

> Renaming things to me feels like a natural progression of the tool. Maybe some criteria can be set around what we choose to rename and why. If there are...

> GHA runners offer some encapsulations around environment-specific issues. In the OSS one I linked above, we use https://github.com/actions-rs/cargo a lot, which encapsulates installing rust, the various targets and some...

@max-sixty I'd like to refocus on the problem that you mentioned. > I'm often writing steps to execute in Task and GitHub Actions or GitLab CI, and don't compound or...

One last thing to mention, is that you said that you were already using `Makefile`, You can of course choose to use `task` and `make` simultaneously, but I'd definitely probe...

> I'd be most persuaded by real examples of this done well. I do agree that more examples, use cases, best/recommended practices need to be documented. I will be working...

Task1 needs Task2 Task1 depends on Task2 I suppose `depends on` reads easier. Regarding other renames. I suppose I should verbalize why I want to rename them. - `desc` and...

Oh, `needs` came from this: https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds