this post was submitted on 01 Jan 2026
221 points (99.6% liked)
Programmer Humor
28287 readers
1018 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Ah yes, I hate the fact that you cannot run GitHub Actions workflows locally in order to debug them.
Kind of can but its easier for me to spam commits to main instead. https://github.com/nektos/act
I've spent so much time trying to get act working well enough that it's easier to use than pushing to remote but it gets really difficult when you involve things like AWS services (especially when the tokens to push to ECR aren't available to me as a lowly dev). Localstack can help but the container registry functionality is locked behind the paid version
The DX of this project is not ideal at all. Like, they are using a different image than GitHub provided, so you get different errors when you deploy… which defeats the entire purpose! That’s if you figured out how to run it locally in the first place after weird errors.
I love the idea of act but pushing to your branch is a lot faster usually
Circleci, Travis, and gitlab all allow you to ssh into the box you are trying your scripts on and fix it there. Much easier and takes a lot less time. Github actions have an unofficial way of doing it and is....not the best. Actions is actually one of the worst CIs I'm my experience.
Their move to attempt to monetize our on-prem runners might be the kick needed to move to Gitlab 🤞
Gl!
That's so silly.
For gitlab this is only correct with a shell executor which is to be avoided in the general case in favor of a docker or k8s executor for isolation&repeatability.
Those you can actually run locally with
gitlab-runner, but then you won't have all your gitlab instance's CI variables so it's a PITA if you need a CI token which you probably do if you actually make decent use of gitlab's features.In most cases I just end up committing my changes to avoid the headache.
:!git commit --amend --no-edit && git push -fgoes pretty dang fast and 60 % of the time third time's the charm.Why avoid the shell executor on docker? I did 4years of gitlab back a bit ago. It was super simple. But I haven't kept up since work maintains actions and Travis. And there's a way nowadays to inject the env or pull from a secret server-ish.
All ci is basically the same. Or at least for a while.
Ideally you'd use the docker executor with a dind service instead of docker commands in the shell. You'll have better isolation (e.g. no conflicts from open port forwards) and better forward-compatibility (the pipeline won't break every time a major upgrade is applied to the runner because the docker - especially compose - CLI is unstable).
I can see the dependencies mucking everything up.
lots of people already pointed out tools to (kind of) dry run locally. they are great to figure out cryptic error messages.
however, if you have issues with the complexity of the whole pipeline, it is usually easier to just execute the whole pipeline. for that we have the branch prefix
cicd/and treat these exactly as main/master and develop (except the very last deployment step). that way we can see where a whole pipeline will go. and when it is finally doing what it should, we can squash it before merge -> have a nice history.I have never used them but there are some tools that advertise being able to run GitHub Actions locally, like WRKFLW.
Try https://nektosact.com/ It’s not perfect, but I was able to do quite a lot locally and have a faster CI development loop.