Hacker News Reader

Comment by xtracto | Hacker News Reader

We are are in a similar situation: We were using Github Team, paying I think $4 a month per account (between 10 and 15 users). I (head of the Eng group) love Gitlab and had used it for some time in personal/open-source projects. I managed to convince the team about Gitlab and we migrated, initially in the Free tier.

My first surprise was that Gitlab does not allow for Monthly payments...if I wanted to go into the Bronze tier, I would have had to pay a whole year in full. My startup doesn't do whole-year payments (quarterly or monthly) so that stopped me on my tracks.

I guess with the full weight of Microsoft, Github will out-price Gitlab. It's kind of sad because I prefer Gitlab CI/CD to Github actions (I just couldn't make sense of them).

View on HN

Invest time in GH actions, they are actually really good once you get over the initial hump.

I love GH Actions so much, though would love dive into GitLab's CI/CD too if anyone has good resources on that.

Here are some options depending on your learning preference:

Video: https://www.youtube.com/watch?v=l5705U8s_nQ

Docs: https://docs.gitlab.com/ee/ci/quick_start/

Slides and a demo exercise: https://gitlab.com/gitlab-de/swiss-meetup-2021-jan

Gitlab's CI/CD a minefield of bad design decisions piled upon each other. Not worth it unless you're stuck with it.

Honestly curious what bad decisions you’ve encountered? I’ve used Gitlab CI/CD on ~20 or so projects of varying complexity (small to enterprise) and have found it enjoyable to use each time.

Would be interested what are your current Problems ?

I'd be interesting in hearing more about some of these.

We're currently using GitLab's CI/CD for ~50 or so private repositories, covering ~7 different languages without any issues. That includes testing, Docker builds and documentation generation for most projects.

We only use private runners though, I don't know if any issues are related to their own runners.

So runners are a good example: The runner config is stored in a config.toml on the runner. If you want autoscaling runners, it gets very complex so you might want to version control it or back it up, but you have to store your AWS secrets in this config.toml. It also contains hashes that have to be matched with settings in the UI, and of course, tags, which need to be tied into your .gitlab-ci. UI configuration changes take places instantly and there's no undo. So you have configuration in 3 places, only one of which is version controlled. And lets say you have some new runners with new tags -- you aren't going to be able to run an old pipeline on the new runner.

Agreed with other commenters, we use gitlab CI extensively, and we find it great. That's the main reason we use gitlab, the code/repository part is not that great and we don't use the other stuff

Talking about bad design decisions, I prefer GitLab's way to handle Pages over GitHub. It's just strange to store generated artifacts in a (`gh-pages`) branch. Instead, in GitLab it's stored as separate files and removed automatically after a certain period.

Reply on news.ycombinator.com