Improve Tasks

[alajmo]

This is an issue to improve the task object. I've gathered the following use-cases:

• [ x] Return correct error exit codes when running tasks
• to be able to access the previous exit code of the previous task
• a summary of task execution at the end
• want a --step mode flag or config setting to prompt before executing a task
• Don't allow duplicate tasks/servers/specs/targets
• Task not callable, only from another task (as not to accidently call it)
• Hide tasks from auto-completion via hidden: true attribute
• Silent output from task via silent: true (and flag)
• ExecTTY should be config shell
• Add flag default_timeout_s
• Use chdir for tasks, work_dir for servers
• Move limit/limitp to spec, or move order to target
• Figure out changed/skipped/when
• Conditional tasks (success, error, skip)
• Add callbacks (success/error)
• Loader show current task and how many left on table
• Add retries to task
• Add required envs
• Add option to prompt for envs
• Handle Match * in ssh config for inventory as well
• Something similar to play, to trigger multiple tasks (with their own context)
• Add env variables to multiple servers
• Run one task, save output from all, and then have one task handle differences
• Save logs/output to files (remote/local)
• Diff task
• Inherit default from default spec/target
• Add yaml to command mapper
• Implement facts
• Configure what to show, host/ip or name, configure via theme/cli flags
• - Template for server prefix, similar to header
• - Add colors to describe (key bold, value color), true (green), false (red)
• - Add Tree output
• Fix hashed ip6 with port 22 does not work, all other combinations work
• Fix sake ssh inv not working

A separate pull-request will be created to implement the necessary changes.

[eppixx]

Currently it is possible to have duplicate task without error.

[alajmo]

Yes, I had plans to rectify that, however, it makes sense to keep it as it is since you might want to override tasks.

So it would be possible to have a task defined in your home config (~/.config/sake/config.yaml) and then override that task if you're working with a config that defines the same task.

[eppixx]

I get that point. But then there should be a way to see which one is overwritten (maybe a flag to check the config).
The worst case scenario is when you have a sprawling config and somebody edits the config and nothing changes because it is overwritten somewhere else.

[alajmo]

I get that point. But then there should be a way to see which one is overwritten (maybe a flag to check the config). The worst case scenario is when you have a sprawling config and somebody edits the config and nothing changes because it is overwritten somewhere else.

I've had some second thoughts here, initially, I thought the use case was valid (users sharing the same code base could override tasks), however, I don't see that use case happening a lot, and that it should take precedence over debugability or worst case, you think you're running a task, but it's some other task you defined in your user config.
Will add it to the roadmap.