I've been writing my own "task runner" which seems to have some of the same features. I'd say some pros: A nice view of that has run (what has failed, etc.) - which otherwise could be drowned-out by stderr and stdout. Timing information for each "task". Can organize nested tasks. Save all in a structured log.
They don't mention a twinkle that many task runners seem keen to omit: how do you handle things where there are human steps involved and not everything is automated? How do you track what has worked and what is still left to do if things go sidesways?
I built baker (https://github.com/coezbek/baker) for this some time ago (pre-LLM mostly). It uses markdown with embedded bash and ruby commands to give you a checklist which is run both automated for commands or with human in the loop for things which aren't automated (like login to some admin panel and generate that key, copy it here).
The checklist gets checked off both by human actions (you confirm that you did it) and automated e.g. success bash command runs. So you keep a markdown artifact on where you are in your project and can continue later.
You can wrap commands to run via SSH (of course clunkier than what scotty here does, but you can select a port for SSH).
I founded and developed a similar concept many years back of a web-based SSH dashboard and management console (Commando.io; which I sold). Now a days I use Semaphore UI [1] which uses Ansible playbooks under the hood in my homelab. Pretty happy with it, though setup and configuration did take a bit to get up and running.
I don't fully get the negativity here. This seems like a middle ground between quick'n'dirty bash script and a well-crafted Ansible playbook.
Half the time if you want to do something quick'n'dirty in Ansible playbooks you need to use shell anyway..
I participated in a hackathon recently where my deployment process was just a bash script doing scp/ssh to a remote server and it feels like Scotty would fit well to that kind of use-case.
20 comments
[ 2.6 ms ] story [ 41.6 ms ] threadIt looks nicer.
I use good old GNU Make.
Ok.
> run them from your terminal and watch every step as it happens
> and watch every step as it happens
Yes, this is usually how scripts work.
> When everything finishes, you get a summary table with timing for each step.
> If a task fails, its output is shown and execution stops right there so you can investigate.
Yes, I write my larger scripts to do such things...
> Writing plain bash instead of Blade
Yes, probably a good idea.
Call me crazy (you're crazy!) but I'm not seeing the point.
I built baker (https://github.com/coezbek/baker) for this some time ago (pre-LLM mostly). It uses markdown with embedded bash and ruby commands to give you a checklist which is run both automated for commands or with human in the loop for things which aren't automated (like login to some admin panel and generate that key, copy it here).
The checklist gets checked off both by human actions (you confirm that you did it) and automated e.g. success bash command runs. So you keep a markdown artifact on where you are in your project and can continue later.
You can wrap commands to run via SSH (of course clunkier than what scotty here does, but you can select a port for SSH).
I named "Ansible for the Frugal"
https://github.com/mikemasam/nyatictl
[1] https://github.com/semaphoreui/semaphore
Half the time if you want to do something quick'n'dirty in Ansible playbooks you need to use shell anyway..
I participated in a hackathon recently where my deployment process was just a bash script doing scp/ssh to a remote server and it feels like Scotty would fit well to that kind of use-case.
https://en.wikipedia.org/wiki/Expect