4 ms·

Why Gitlab CI? What makes it better than Jenkins?

by nubela 10y ago

petepete 10y ago
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).
- sytse 10y ago
  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 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 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 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 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 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 https://gitlab.com/gitlab-org/gitlab-ce/issues/24361
  - supergreg 10y ago
    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.
    - sytse 10y ago
      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?
      - supergreg 10y ago
        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.
        sytse 10y ago
        The Bitnami package indeed doesn't include any of this. I strongly recommend switching to Omnibus. From https://about.gitlab.com/installation/ 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."
- mi100hael 10y ago
  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.
  - sytse 10y ago
    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.
    - mi100hael 10y ago
      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.
      - sytse 10y ago
        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/master/docs/commands/README.md#interactive-registration 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+builds https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...

Why Gitlab CI? What makes it better than Jenkins?

by nubela 10y ago

Why Gitlab CI? What makes it better than Jenkins?

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).

sytse 10y ago
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 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 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 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 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 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 https://gitlab.com/gitlab-org/gitlab-ce/issues/24361
- supergreg 10y ago
  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.
  - sytse 10y ago
    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?
    - supergreg 10y ago
      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.
      - sytse 10y ago
        The Bitnami package indeed doesn't include any of this. I strongly recommend switching to Omnibus. From https://about.gitlab.com/installation/ 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."
mi100hael 10y ago
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.
- sytse 10y ago
  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.
  - mi100hael 10y ago
    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.
    - sytse 10y ago
      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/master/docs/commands/README.md#interactive-registration 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+builds https://wiki.jenkins-ci.org/display/JENKINS/Distributed+buil...