83
GitHub Actions Is Slowly Killing Your Engineering Team - Ian Duncan
(www.iankduncan.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 27 Mar 2026
83 points (94.6% liked)
Programming
26276 readers
257 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 2 years ago
MODERATORS
I agree with everything he said, but I'm currently living in the simple, honest truth of God's own "bash" just like he describes and I'm loving it. Maybe someday I won't. Maybe someday will be soon. Maybe my bash scripts are horrible nightmare fuel. But they're also my children. I love them. Even the ugly ones.
I do indeed "have 800 lines of bash that reimplements job parallelism with wait and PID files, has its own retry logic built on a for loop and sleep, and parses its own output to determine success or failure." I do suspect the script is self-aware. This pleases me. I will bend to its desires. If there comes a time when it no longer desires to perform CI for me, I will respect its wishes.
Why not use python at that point? Sounds like the bus factor would be pretty big on this one
This the most logical solution. Python is what you (should) turn to when your Bash scripts start looking like real software. Whenever I see a (non-geriatric) developer with a giant bash script, my first assumption is that this is a junior dev who doesn't know better.
Bash that can do the same job regardless of ci tools is underrated. I likevthat setup too because if your tesm eber needs to run a job/deploy/ect they can with the same exact processes the ci employs.