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).
gglitch 9 hours ago [-]
I already commented about Expect elsewhere in this thread, so I should probably pipe down, but thought it might be worth it here as well because Expect has been handling these kinds of exceptions and control transfers/flows with the full power of a robust programming language for decades. You might have a look at it for ideas and inspiration.
This is such a neat idea. I am going to adopt this for my own workflows as well, right now I just write private blog entries for stuff I do that I may forget how to do later (provisioning a server, networking, caddy setup, etc etc)
Thanks for sharing!
qmr 1 days ago [-]
> It lets you define deploy scripts and other remote tasks
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.
giobox 1 days ago [-]
It also (criminally for an SSH tool) appears for now to only work when the server uses the SSH default port 22:
Literally would be one of the first things I would have tested personally!
SrslyJosh 1 days ago [-]
This is where I stopped reading:
> Scotty was built with the help of AI
So it sounds like my heuristic worked. =)
steve_adams_86 21 hours ago [-]
We need a term like potempkin-ware or something to express "I just built a 3 week project in 3 hours and, although it looks nice, there's probably a ton of problems with it because I couldn't possibly review everything Claude puked out properly, use at your own risk".
monooso 20 hours ago [-]
If you don't use any AI assistance when coding I suspect you're already in the minority.
If you refuse to use software that was built with any AI assistance, well... good luck finding an operating system to run.
mariocesar 24 hours ago [-]
I made something similar years ago, a long one-liner.
Ansible only exists because of an influx of people who don't know how to do this.
everforward 20 hours ago [-]
Ansible exists because it makes things idempotent, which is great when you have to do a thing on 1,000 servers because you can just fix the role and re-run it.
Bash can be idempotent but isn’t by default, so you either spend time making and idempotent bash script or you spend time learning Ansible to accomplish the same thing in a reusable way
wang_li 7 hours ago [-]
Ansible’s idempotency is dependent on the specific module being invoked. What ansible mainly brings to the table is the parameterized modules. Which brings us back to people adopting it because they don’t know how to compose one liners, quote them properly, and wrap them in a for loop.
icedchai 22 hours ago [-]
Many years ago I wrote my own "cloud instance bootstrapper" that would pull a tar off of S3 based on EC2 instance tags / metadata, untar it, then run a script. I never got into Ansible and I hated having to rebuild AMIs for minor changes.
22c 20 hours ago [-]
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.
gglitch 9 hours ago [-]
I use Expect for this, and have for a long time. It’s amazing.
The most obvious question, I know, but... why not just use plain Bash?
SoftTalker 1 days ago [-]
Or something like Ansible? Which is battle tested, provides idempotency for most things, and has a large library of tasks it knows how to do.
mathfailure 1 days ago [-]
Scotty doesn't know...
Piraty 1 days ago [-]
every sunday
ks2048 23 hours ago [-]
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.
metalliqaz 1 days ago [-]
It's in the title: "a beautiful"
It looks nicer.
I use good old GNU Make.
mikemasam 23 hours ago [-]
Doing DevOps everyday, i got to experiment with this idea, something minimal
Feels like Ansible does the same thing, just with nicer output
verdverm 24 hours ago [-]
Feels like Ansible has more in the pros column than just nicer output, imo
tkiolp4 23 hours ago [-]
Just use (the good parts of) Ansible
nodesocket 23 hours ago [-]
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 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).
https://en.wikipedia.org/wiki/Expect
Thanks for sharing!
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.
https://github.com/spatie/scotty/issues/1
Literally would be one of the first things I would have tested personally!
> Scotty was built with the help of AI
So it sounds like my heuristic worked. =)
If you refuse to use software that was built with any AI assistance, well... good luck finding an operating system to run.
I named "Ansible for the Frugal"
Bash can be idempotent but isn’t by default, so you either spend time making and idempotent bash script or you spend time learning Ansible to accomplish the same thing in a reusable way
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
It looks nicer.
I use good old GNU Make.
https://github.com/mikemasam/nyatictl
[1] https://github.com/semaphoreui/semaphore