Add `if:` keyword to control when a task or command is ran?

[ProfessorManhattan]

There are some cases where task: is called under cmds: and the task needs to be conditionally run. Take the following as an example:

---
version: '3'

tasks:
  python:requirements:
    deps:
      - :install:software:python
    run: once
    cmds:
      - task: python:requirements:poetry
      - task: :{{if eq .REPOSITORY_TYPE "ansible"}}common:python:requirements:ansible{{else}}donothing{{end}}
    status:
      - '[[ "${container:=}" == "docker" ]]'

I'm currently getting around the issue by having a task called donothing that gets called when the task should not run. It would be nice if we could conditionally run tasks somehow. Maybe something like this:

---
version: '3'

tasks:
  test:
    cmds:
      - task: anothertask
        when:
          sh: '[[ "$CONTAINER" == 'docker' ]]'

[andreynering]

Hi @ProfessorManhattan,

Something I had in mind for a while is that we could potentially have an if keyword for tasks and commands:

version: '3'

tasks:
  foo:
    cmds:
      - echo 'bar'
    if: '[[ "$ENV" == "bar" ]]'

or

version: '3'

tasks:
  foo:
    cmds:
      - cmd: echo 'bar'
        if: '[[ "$ENV" == "bar" ]]'

NOTE: We already have preconditions, which is similar but makes the call fail when an error is returned, which means if still makes sense to have for skipping without failing.

[ghostsquad]

isn't that what status is supposed to do? decide to skip a step?

Unlike status which will skip a task if it is up to date, and continue executing tasks that depend on it, a precondition will fail a task, along with any other tasks that depend on it.

[andreynering]

isn't that what status is supposed to do? decide to skip a step?

You have a good point, we'd have some intersection between these two features.

status currently prints Task "foo" is up-to-date messages, though. This is accurate for statuses but not for other reasons why you'd want to skip a task.

Also, if would be the opposite of status with regarding the expected status: if runs on zero, status runs on non-zero statuses.

So, I don't have a strong opinion, but maybe it would still make sense to have both if and status. Alternatively, we could add if: only to commands and not to the task itself.

[ProfessorManhattan]

Thanks @andreynering

Another thing we might want to keep in mind is handling the --force command line parameter. Currently, this will just ignore status which forces the user to wrap everything in ifs (even using status) for logic that doesn't relate to a particular project. In my use case, I share the same set of Taskfiles across hundreds of repositories of many different types - it is not feasible to generate the Taskfiles for each project type.. it would take too long.

I would like to see an if: that can be added at the least to the task and cmd level. It should also not be impacted by any --force logic. Take the following example:

---
version: '3'

tasks:
  mytask:
    cmds:
      - gsettings set org.gnome.settings-daemon.plugins.color night-light-enabled true
    if:
      - ls /usr/bin/*session | grep gnome-session
    status:
      - [[ $(gsettings get org.gnome.settings-daemon.plugins.color night-light-enabled) == 'true' ]]

Both the if: and status: are used in this example. The if: parameter makes sure GNOME is being run on the system and the status: is used to achieve idempotency. This would make even more sense if we were running a command that requires a reboot. In this example, we would need the --force command to obey the if: or else we would get an error if GNOME is not on the system.

Currently, with any complex flows that rely on status, things can easily get messy when using --force but the --force command could potentially be pretty useful for cache busting. I see adding an if: parameter as a possible solution.

[ssbarnea]

Probably the best use-case for if would be to add steps that depend only on specific platforms, like Windows, Linux, MacOS. Adding extra code for platform on each called shells script is a PITA, one that could be easily avoided with an "if".

[andreynering]

For those interested, there's an ongoing discussion about a possible key specificly to select given OS/Arch on a task or command:

• [Proposal] Inline platform/arch key for commands #978
• Add support for 'platforms' in both task and command #980

[max-sixty]

A +1 for if.

I really over-use status, which requires some mental gymnastics ("Only run this on ARM machines, which means status needs to be 0 on x86 machines, so raise an error on ARM"!), and isn't compatible with --force ("now we're running it on x86 machines?!")

Though I do empathize that it still has lots of overlap with status...