Comment by nicoburns
7 months ago
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.
> 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.
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?
2 replies →
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?
3 replies →