Reset task status if definition has changed

[superlevure]

Hi,

First of all, thanks for the great tool!

Currently if you use sources to watch for changes and update the task definition, the task will still be marked as up-to-date even if you completely changed the logic behind it. I think it would make sense to "reset" the task status whenever its definition has been updated.

[andreynering]

Hi @superlevure, and thanks for opening this issue!

I think this is an interesting proposal, but I'm not sure everyone would think this is the desired behavior. Hearing more opinions would be interesting.

---

Implementation note: we could use https://github.com/mitchellh/hashstructure to calculate the hash of the task and compute that in the checksum.

• This means it wouldn't work in timestamp mode
• This could have a side-effect of invalidating the checksum when upgrading the Task version if we make changes to the schema. Possible mitigation: Perhpaps considering only deps: and cmds: would be enough?

[postlund]

I was about to write an issue about this as I'm struggling with the same problem right now. Very interested in a solution to this. A pessimistic approach, where any change to a Taskfile.yml would trigger a re-build, would be good enough for me. Maybe a generic solution could be used with different strategies to resolve if re-builds should be forced (that way better solutions can be added over time and no one is forced to use it)?

[ghostsquad]

I like the idea of including the task definition (in it's entirety) in the hash. It's likely very error prone to try to actually figure out how something may have changed and be selective.

[per1234]

A pessimistic approach, where any change to a Taskfile.yml would trigger a re-build, would be good enough for me.

I haven't had the chance to take advantage of the feature yet, so might well be missing something, but doesn't task already provide this capability?

sources: 
  - Taskfile.yml

[postlund]

I like the idea of including the task definition (in it's entirety) in the hash. It's likely very error prone to try to actually figure out how something may have changed and be selective.

I like that too, especially since that would mean that (environment) variables are taken into account for as well, which would otherwise go unnoticed.

[postlund]

A pessimistic approach, where any change to a Taskfile.yml would trigger a re-build, would be good enough for me.

I haven't had the chance to take advantage of the feature yet, so might well be missing something, but doesn't task already provide this capability?

sources: 
  - Taskfile.yml

Yes, should work, but it assumes you do not use any includes. Which I use a whole lot of.

[ghostsquad]

Even though you can use sources (built in), it makes a lot of sense to make this default behavior.

[frenchfrywpepper]

I like the idea of including the task definition (in it's entirety) in the hash. It's likely very error prone to try to actually figure out how something may have changed and be selective.

I'd be in favor of this approach. I'm currently adding the Taskfile itself to my sources as a workaround, but this catches more changes than are strictly necessary. Including the definition in the checksum is something I had assumed would occur, but discovered was not happening.

[pd93]

I don't fully agree with this change. I can definitely see the advantages of it in certain cases. However, there are definitely scenarios where this will cause problems.

There are a few different things being talked about here:

1. Hashing the entire Taskfile.yml and invalidating all task hashes if it changes.
2. Hashing individual tasks and invalidating that task's hash if its definition changes.
3. Hashing a subset of task attributes and invalidating the task's hash if those attributes change.

---

The first option is not practical because of "setup tasks". For example:

version: '3'

tasks:
  generate-one-time-certificate:
    status:
      - test -f certs/my-cert
    cmds:
      - gen-cert

  run-my-thing:
    deps: [generate-one-time-certificate]

I absolutely do not want to regenerate this certificate if I change something unrelated in the Taskfile. But I don't think this is really the feature people are asking for.

---

The second option has problems too. If I change the task definition like this:

    version: '3'

    tasks:
      generate-one-time-certificate:
+++     desc: Generates a one-time certificate
        status:
          - test -f certs/my-cert
        cmds:
          - gen-cert

Do I really want to rerun the Task? Probably not. The status check hasn't changed and the command to generate it hasn't changed either. Sometimes we only want to run commands if we really need to and I would rather "not run something when it should have run" than "run something when it shouldn't have". I don't think hashing the entire task definition makes sense.

---

Perhaps considering only deps: and cmds: would be enough?

This makes a lot more sense as by changing what the task does, you are invalidating what it did on the last run by definition. However, I'm still concerned that this change of default behaviour will catch someone out. (Do we consider this a breaking change?)

For me personally, I'm happy just to run --force when I update a definition, but the status checks are still passing - Especially now that we're going to have the gentle force experiment.