You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 0negative:
cmd: exit 2test-positive:
preconditions:
- task: positivecmd: echo "I am OK"test-negative:
preconditions:
- task: negativemsg: Precondition negative failedcmd: echo "I am not ok"test-invalid:
preconditions:
- task: positivesh: 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.
The text was updated successfully, but these errors were encountered:
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.
Using
task: ...
inpreconditions
This feature requests aims to allow using
task: ...
property inpreconditions
array of a task.Currently,
preconditions
is an array of either string (interpreted as shell commands) or an array of objects withsh
(also interpreted as a shell command) andmsg
(interpreted as a string) being printed when given shell command exits with a return code != 0.Example:
Acceptance criteria: (check indicates whether current behavior fulfills the criteria)
task positive
should not do anythingtask negative
should fail with exit code 2task test-positive
should check the preconditiontask test-positive
should printI am OK
task test-negative
should check the preconditiontask test-negative
should printPrecondition negative failed
exit with an error code 1task test-negative
should not printI am not OK
task test-invalid
should not be validBackwards compatibility is assured, as this is just an expansion to the existing object used as an array item in
preconditions
. Using bothsh
andtask
should not be valid declaration of a precondition.Using
task: ...
instatus
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.The text was updated successfully, but these errors were encountered: