Ah yes, I hate the fact that you cannot run GitHub Actions workflows locally in order to debug them.
this post was submitted on 01 Jan 2026
232 points (99.6% liked)
Programmer Humor
28609 readers
1648 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
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 -f goes 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.
Yeah, we always try to automate as much as possible with generic language build tooling and scripts, so that ideally the call in the runner is just a single command, which can also be triggered locally.
Unfortunately, if you want to be able to re-run intermediate steps, then you do need to inform the runner of what you're doing and deal with the whole complexity of up-/downloading intermediate results.
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.
Solution:
git commit --amend
git push --force
Problem:
The process of discovering best practices on how to keep a clean git history is a goddamned challenge.
--force-with-lease* 🙃
I didn't want to make it sound too scary 😉
Seriously, though, git really needs an option to treat --force as --force-with-lease. In the exceedingly rare occasion where I might want to completely overwrite a branch, it should be extra explicit by having to type something like --force-and-overwrite.
--force-overwrite-everything-i-know-what-the-heck-i-am-doing
just to be sure...
(/j)
At this point, it may be a good idea to throw the entire git porcelain (frontend) away and redesign it from scratch!
Yeah, I virtually only use --force for moving tags around (which one could definitely argue isn't really a thing you should be doing regularly either)...
Don't waste your precious build minutes: act, gitlab-ci-local.
I find it infuriating that they didn't design CI to run locally first and then offer a hosted version of it. These tools are not the perfect alternatives for the real thing.
That's why I use a separate branch. Use rebase or reset depending on what exactly you need to clean up when it's working.
Yeah that's me some days at work