Allow using tasks in `preconditions` (possibly `status`)

[DerpgonCz]

Using task: ... in preconditions

This feature requests aims to allow using task: ... property in preconditions array of a task.

Currently, preconditions is an array of either string (interpreted as shell commands) or an array of objects with sh (also interpreted as a shell command) and msg (interpreted as a string) being printed when given shell command exits with a return code != 0.

Example:

version: '3'

tasks:
  positive:
    cmd: exit 0

  negative:
    cmd: exit 2

  test-positive:
    preconditions:
      - task: positive
    cmd: echo "I am OK"

  test-negative:
    preconditions:
      - task: negative
        msg: Precondition negative failed
    cmd: echo "I am not ok"

  test-invalid:
    preconditions:
      - task: positive
        sh: exit 1

Acceptance criteria: (check indicates whether current behavior fulfills the criteria)

• ✅ Running task positive should not do anything
• ✅ Running task negative should fail with exit code 2
• ❌ Running task test-positive should check the precondition
• ✅ Running task test-positive should print I am OK
• ❌ Running task test-negative should check the precondition
• ❌ Running task test-negative should print Precondition negative failed exit with an error code 1
  • not sure if it should inherit the error code or not
• ❌ Running task test-negative should not print I am not OK
• ❌ Running task test-invalid should not be valid
  • or throw a validation error on running any task, as the file is technically not valid

Backwards compatibility is assured, as this is just an expansion to the existing object used as an array item in preconditions. Using both sh and task should not be valid declaration of a precondition.

Using task: ... in status

Similiar as above, however it is an expansion to allowed structure for status, as it currently does not allow objects, but only strings. It is possible to create a new feature request if these two features in one request are a different scope, but I did not want to create a new issue for it and would rather see if the above passes before creating it.

Afterword

I am aware that deps are already usable, however it is not possible to use --force to skip them.

[trulede]

Perhaps look at #1200 which seems like it would solve your problem (with the --force flag).

https://taskfile.dev/experiments/gentle-force/

[DerpgonCz]

Perhaps look at #1200 which seems like it would solve your problem (with the --force flag).

https://taskfile.dev/experiments/gentle-force/

This is different, this is an expansion to existing logic where you can call tasks in preconditions and status, and has nothing to do with the --force flag.

I have a few preconditions and status-es that I would like to run, but have to either use YAML anchors (if I do not want to duplicate logic) or run other tasks with task xxx (which does not work in included Taskfiles). The logic is basically the same as with deps, where the strings are tasks by default.

This keeps the default logic of running shell command when only a string is provided, but can be expanded to run tasks (similarly to cmds/cmds attribute in tasks) where if you supply an object with { task: xxx } it will run that task, capture the response code, and behave the same way as if it was a regular shell command.

[ChrisPbb]

I found a workaround for this but I can't say I'm proud of it 😅. You can call the task CLI from status and preconditions 👼

version: "3"

tasks:
  random-fail:
    cmds:
      - exit {{randInt 0 2}}

  default:
    status:
      - task random-fail
    cmds:
      - echo Not skipped.

[eatmyrust]

This would be useful for reducing duplication of preconditions within a Taskfile and for sharing them across Taskfiles. As @DerpgonCz mentioned the current solutions are yaml anchors, which cannot be shared across Taskfiles, or calling the task cli which does not work in included Taskfiles. I would also prefer not to move to deps because I would like to continue taking advantage of the error messages that preconditions provide to the user.