Hacker News Reader

Comment by petepete | Hacker News Reader

I think the consensus is that Jenkins offers more power and flexibility at the cost being more complicated to set up. GitLab CI is easier to get up and running with and superbly integrated with GitLab (as one would hope).

View on HN

We also want to offer all the power and flexibility of Jenkins but we still have some work ahead of us. The idea is to add those features to GitLab itself and not to plugins. Plugins tend to cause brittleness https://news.ycombinator.com/item?id=13218391 We want to make sure that you can upgrade GitLab without having to worry about things breaking.

For the current GitLab release (8.15, December 22) we planned the following CI improvements (not all will be ready, some will slip to Jan 22):

Pipelines for Merge Requests https://gitlab.com/gitlab-org/gitlab-ce/issues/23902

Remove Builds tab from Merge Requests and Commits https://gitlab.com/gitlab-org/gitlab-ce/issues/23638

Make pipeline graph nodes bigger and responsive https://gitlab.com/gitlab-org/gitlab-ce/issues/22088

Direct link from pipeline list to builds https://gitlab.com/gitlab-org/gitlab-ce/issues/19703

Part of the issues in Improve reliability of CI/CD https://gitlab.com/gitlab-org/gitlab-ce/issues/24361

Does these pipelines thing imply moving away from Sidekiq? At work that's our biggest issue with Gitlab. Sidekiq dies all the time and Gitlab has to be restarted for merge requests to work again.

These pipelines do not imply moving away from Sidekiq. Have you tried using the Omnibus package? It contains logic to make sure restarting Sidekiq is automatic. How much memory does GitLab have and how many users?

Only 5 users. We are using Gitlab from Bitnami which I'm sure is using the Omnibus package. Maybe they configure it differently. I'll check, thanks.

The Bitnami package indeed doesn't include any of this. I strongly recommend switching to Omnibus.

From https://about.gitlab.com/installation/ "One-click installers are frequently out of date and might not contain our Omnibus packages. An example of this are the Bitnami packages in the past couldn't be updated and are now much harder to update than the Omnibus packages. We advise to not use one-click installers but instead start an vanilla Ubuntu instance and use the recommended Omnibus package installation. This is almost as quick as a one-click install and you're sure of the latest version and easy upgrades."

I dunno, I found the opposite. Jenkins is an easy stand-alone package that I can just install & immediately navigate to the UI. GitLab-CI requires you to install & configure & link "runners" in a manner that I found less intuitive.

We're always interested in making that experience better. The reason that it is more complex than Jenkins in the first place is that we think the builds should happen on another instance than the one GitLab is running on. I've seen running the builds on the Jenkins machine lead to many problems. Hence the need for our process that we try to make easier than setting up Jenkina build slaves while still being secure when working on the public internet.

Interesting, thanks for the insight. Those are certainly valid reasons for things being the way they are, but I have to wonder how many GitLab installs are like mine: a single "git/build" server on a private network serving a small group of users. I'd wager the number of installs that fall into that category is fairly substantial, and in that situation the runner configuration feels pretty over-engineered.

I agree it is a tradeoff. It is very hard to make both local and remote easy. We opted to make the right thing the easy thing to do. That means it is harder to set up than Jenkins that default to local builds. But we hope the experience of https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/ma... is a lot easier than setting up build slaves in Jenkins https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...

Reply on news.ycombinator.com