sake Improve Tasks

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
[x] to be able to access the previous exit code of the previous task
[x] a summary of task execution at the end
[x] 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.

Jun 17 '22 15:06 alajmo

Currently it is possible to have duplicate task without error.

Jul 19 '22 15:07 eppixx

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.

Jul 20 '22 20:07 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.

Jul 20 '22 22:07 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.

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.

Oct 09 '22 21:10 alajmo