4 ms·

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 insta

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