Hacker News Reader

Hacker News

Comment by nicoburns | Hacker News Reader

Parent Full thread

nicoburns

For me the big problems with CI setups tend to be:

- They're often slow

- They're often proprietary

- They're often dealing with secrets which limits who can work on them

- You generally can't run them locally

So the feedback cycle for working on them is incredibly long. And working on them is therefore a massive pain.

View on HN

> You generally can't run them locally

I recognize that this is such a disincentive for me taking the initiative to fiddle with and learn about anything like this

Same goes for anything "enterprisey". Last time I set up a big project, I made a commitment that "we should be able to check out and build this whole thing, for as long as humanly possible".

The local part is my big problem too. I used azure Dev ops in work. I find clicking through the UI to be a miserable experience, Id love to have it running locally so I could view inputs and outputs on the file system. Also yaml is an awful choice, no one I know enjoys working with it. The white space issues just get worse and worse longer your files get.

> You generally can't run them locally

GitLab CI gives you local runners. You can completely self-host CI.

Well, yes, but aren't those runners have different configuration than the runners that are actually deployed and used by your company's CI/CD?

Wat? Our company's CI is GitLab CI, self-hosted. What other runners would we need?

The local ones, mentioned in the original comment that we've been discussing in this thread? The local runner, executing on the developer's machine.

Of course it makes no difference whether that runner runs on our local CI host or on my dev machine.

I think GP got confused, it's not running the runners locally, it's running the CI steps locally (see the other sibling replies).

For example, running tests locally exactly the same way as in the runner - sometimes I have to open a debugger in the middle of a test to see what exactly went wrong. Our tests run in gitlab in a particular docker image, and I've been adding a "make test" that runs the same tests in the same image locally, with additional flags to have full interactivity so the debugger works if needed.

It's not self hosting. It's can I run the build from my local command line and get the same results.

How is running those runners on our own hosts (locally) not self-hosting?

Spoken like someone who has not tried what you are describing. There are two moving parts to your response: a locally hosted runner awaits jobs from GitLab itself, which doesn't help running _locally_, and the other part is that -- back when it existed! -- trying $(gitlab-runner exec) was not a full fledged implementation of the GitLab CI concepts, making it the uncanny valley of "run something locally."

However, as of v16 there is no more exec https://gitlab.com/gitlab-org/gitlab/-/issues/385235 which I guess is good and bad. Good in that it not longer sets improper expectations that it could have plausibly done anything, and bad in that now it joins GitHub Actions[1] in not having any _local_ test strategy aside from "boot up gitlab/gitlab-ce && echo good luck"

1: yes, I'm acutely aware of the 3(?) implementations/forks of nektos/act that claim to do GHA but, again, readme is not software and I can tell you with the utmost certainty they do not do as advertised

Not to mention that the rest of the environment is missing: e.g. you probably can't push to e.g. the organization's Docker registry/Artifactory/whatever from you local dev machine (if it's even visible from your machine in the first place). And those are arguably the most interesting parts that you want to test the integration with.

Reply on news.ycombinator.com