feat: add global precondition

[vmaerten]

Fixes #294

It's a fairly popular feature

[vmaerten]

I was wondering how it should behave if an included Taskfile defines global preconditions:

1. Should it produce an error (similar to dotenv)?
2. Should all preconditions be merged and applied together?
3. Should the global preconditions in the included Taskfile be ignored?

I started with the 2 in mind, but I am not sure anymore

Any thought ? cc @pd93 / @andreynering

[pd93]

As a user, I would expect 2. This is also the safer option if we maintain the principle of "its safer to not run a task that was intended to run than it is to run one that wasn't."

[vmaerten]

I followed the same pattern we have with vars.
I am not a huge fan of naming preconditions inside preconditions, maybe values ?
I you have some naming ideas

[pd93]

Thanks for working on this! It's definitely a key feature. A couple of bits that need discussion though.

[pd93]

I've moved Vars and Var into separate files in another PR. Would be good to follow this pattern here.

[pd93]

I would expect the global preconditions to run first. For example:

version: '3'

preconditions:
  - test -f foo.txt

tasks:
  default:
    preconditions:
      - test -f bar.txt
    cmds:
      - echo "default task"

Assuming that neither file exists, I would expect to see

task: `test -f foo.txt` failed
task: precondition not met

Also prefer slices.Concat over append and ... now that its in the std lib.

Suggested change

	for _, p := range append(t.Preconditions, e.Taskfile.Preconditions.Preconditions...) {
	for _, p := range slices.Concat(e.Taskfile.Preconditions.Preconditions, t.Preconditions) {

[pd93]

Because we don't have scoping, this is going to lead to issues where global preconditions in included Taskfiles are going to impact tasks in parent files. I think this is going to be pretty unintuitive to users at the moment. For example:

# Taskfile.yml
version: '3'

includes:
  include: include.yml

tasks:
  default:
    cmds:
      - echo "default task"

# include.yml
version: '3'

preconditions:
  - test -f foo.txt

task: `test -f foo.txt` failed
task: precondition not met

We could:

1. Leave as it is, vars already behaves like this. We'll fix it later 🤷‍♂️
2. Not allow global preconditions in included taskfiles for now
3. Not merge this functionality until scoping is ready

I think 1 is pretty reckless. We're essentially intentionally adding behaviour that we know is confusing and will raise questions.

3 is very conservative while 2 is a good compromise. It depends how urgently we want to roll out this functionality. If we don't think its urgent then maybe we wait. The question is how long will scoping actually take? I've already taken a stab at it and I can tell you - it's significant piece of work.

[pd93]

I completely missed the previous comments when reviewing this 😆 Including my own.

I followed the same pattern we have with vars. I am not a huge fan of naming preconditions inside preconditions, maybe values ? I you have some naming ideas

Yeah, Preconditions.Preconditions does stutter. I think Values is fine, This is what we do for Vars.

I was wondering how it should behave if an included Taskfile defines global preconditions:

1. Should it produce an error (similar to dotenv)?
2. Should all preconditions be merged and applied together?
3. Should the global preconditions in the included Taskfile be ignored?

I started with the 2 in mind, but I am not sure anymore

Any thought ? cc @pd93 / @andreynering

As a user, I would expect 2. This is also the safer option if we maintain the principle of "its safer to not run a task that was intended to run than it is to run one that wasn't."

I didn't think about the scoping issues when writing this comment originally. I think option 2 is still the long-term goal here, but we might have to think about doing something like 1 or 3 in the meantime. See #1993 (comment)

---

P.s 10 years on this platform and I've only just noticed that if you highlight text in a comment before clicking "Quote Reply", it will only quote the selected text 👀 Amazing.