Hacker News Reader

Comment by Volundr | Hacker News Reader

Yeah this is a pain point for me as well, especially when developing the pipelines themselves. There's no good way to run it on my own machine, so I'm stuck pushing new commits to Gitlab over and over again and waiting for it to complete, or rather fail so I can troubleshoot the new error.

View on HN

Depending on one's definition of "good," running GL locally in docker is (in my experience) painless, given sufficient disk space and probably RAM

But yes, your observation is my whole complaint: it is not _reasonable_ to ask a GLCI developer to run a local copy of GL, complete with any shared GLCI template repos, in a local docker container just to have local execution. Maybe I wouldn't complain about it so much had I not started with circleci so long ago and had such a "wow, this is amazing" followed by gitlab-runner's :troll_face: -- to say nothing of GitHub Actions just straight up ignoring that whole demographic and hoping https://github.com/nektos/act emulates enough to have people not notice the massive feature gap

unfortunately `act` is pretty bad :(

My go to workflow for workflows (ha) is forking a repo as a private fork and toying on it until I'm happy with the results

This thread makes me wonder if the root of the problem is actually the lack of a local runner. I hypothesize that it's the length of the feedback loop that's the real issue.

Even if we had a local runner, if it takes a ton of time to start and complete every step, it'd be almost as painful to debug as a remote runner taking the same time. On the other hand, if the cloud runner is ridiculously fast, and completes steps on the order of single digit seconds, it would be fairly painless to debug.

Not really. I mean yes my dev machine is faster than the CI runner, so things do run faster, but even assuming the CI runner was just as beefy and picked up the job immediately instead of taking 10ish seconds it's still the difference between

When running remotely: edit file > commit > push > switch to browser > browse to pipeline > repeat

Vs locally: edit file > run pipeline > repeat.

If you have access to the Kubernetes cluster or wherever your runner is running: put a sleep right before the error, execute into the running pod and debug it.

I like to do gitlab-runner exec docker … locally, but it doesn’t work with includes and you need to set up your own variables.

Reply on news.ycombinator.com