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]

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.

[vmaerten]

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)

I think scoping can take some time to roll out, and we could benefit from this feature soon. I agree with you that option 2 is the long-term goal.

I've chosen to produce an error if a precondition is in an included Taskfile. Why? Because I prefer explicit over implicit.
Of course, it can be challenged.

We could merge this feature now and improve it once the scoping feature is ready.

---

P.S : I did not know too, thanks !!