Hacker News Reader

Comment by knocte | Hacker News Reader

IMO moving from Travis to Jenkins seems like a very disruptive change.

As for me, I had used Travis just a bit, and same for Jenkins, and didn't like any of those options very much.

So when my team needed to setup a CI solution, we ended up using GitLab CI, and it brings the best of both worlds:

- Free service version if you use the GitLab.com deployment (granted, gitlab.com is a bit slow because it's the new thing and everybody is using it now), like travis.

- Open source so that you can host it yourself in the future if you need to, like Jenkins.

- Easy to use and configure, like Travis.

- Free service for private repos in GitLab.com (neither Travis nor any Jenkins-service provider offer this, AFAIK).

I plan to never look back.

View on HN

Thanks for your kind words about GitLab. We're working hard on making GitLab.com faster, see https://gitlab.com/gitlab-org/gitaly/issues/ for the latest. A workaround would be to run your own GitLab installations, all the CI features are in the open source GitLab CE https://about.gitlab.com/products/#comparison

For an intro to Gitlab CI see https://about.gitlab.com/gitlab-ci/

Honestly my experience is that SaaS / hosted CI is just generally annoying due to constant stability and performance (both transient and in general, eg. caching in Travis) issues.

Self-hosted CI on the other hand requires a lot of resources, especially when you're not only testing Linux or BSD, but proprietary OSes (OSX, Windows, although the latter at least has the Edge images that work everywhere).

Ultimately I feel like the use of CI in many open source projects isn't very high due to constant annoyances and difficulty debugging the CI environment.

Just a note - you can host your own CI node (runner) for project(s) on gitlab.com. It's super simple to setup, too.

https://docs.gitlab.com/runner/install/linux-repository.html

This doesn't solve issues in runner-to-base comms. I had tried this kind of setup relatively recently, and almost every 10-15th build had failed for me because GitLab wasn't healthy (502 from Docker registry or problems up/downloading artifacts between stages, etc.)

Fully self-hosted looks like the only sane way. Harder to set up, but at least one can check the whole chain that way.

Sorry about GitLab.com having performance problems. Self hosted is indeed the only way to work around it in the short term. I hope you can set it up quickly. Please use the Omnibus packages that should install in a few minutes https://about.gitlab.com/installation/

> Ultimately I feel like the use of CI in many open source projects isn't very high due to constant annoyances and difficulty debugging the CI environment.

My perspective may be driven by the communities I'm involved in, but this seems wrong to me. From my experience I would say most open source projects use CI, particularly because so many of the bigger platforms (Travis, Circle, CodeShip) make it free for open source.

It is an extremely valuable resource when you consider the infrastructure and integration you get with absolutely no effort. Installing more obscure libraries or cutting edge releases can be a pain, but it is minuscule compared to the time it would take to provision, secure, and manage a group of containers for an open source project.

Do you really find Travis easy to use and configure?

I've used TeamCity a lot and find the functionality to be decent to good but the UI horrible. Perhaps a bit biased because I had access to the server and agents in that case. A lot of debugging/discoverability issues are easier with full access of course.

I've then used Travis a bit for small GitHub projects (and contributing to other people's projects) and it has a nice UI for simple stuff. However, it gives the impression that they are struggling to stay alive - many features are in beta or feel like they are; a lot is under-documented or planned soon (for multiple years). I know I can dig into their various projects' source code to find out how things work, but I always feel incredibly unproductive figuring something out in Travis. I worry for them. Great to hear you have a good experience with GitLab!

I'll definitely check it out - but the problem with many of these tools is a lack of "proper" Docker support, along with the ability to self host and debug. Thanks for the heads up!

GitLab CI has proper Docker support. You can set a default docker image for each runner `--docker-image ruby:2.1` or set one for the project in the .gitlab-ci.yml file. For more information see https://docs.gitlab.com/ce/ci/docker/using_docker_images.htm...

Did you know GitLab also comes with a private container registry? https://about.gitlab.com/2016/05/23/gitlab-container-registr...

Thanks for clarification - I'll definitely have a look :)

Also notable is services like docker-in-docker (and privileged docker containers) are allowed, which is a huge win over services like Atlassian's Pipelines.

Without dind, it's really hard/annoying to us CI/CD to build docker images. But with Gitlab, they also provide a place to store docker images (the "registry") right next to your code, for free!

At work, we're investigating moving to Gitlab for everything except issues (which we'd need to keep on JIRA for now since we're so embedded with it). It looks like Gitlab does have some integration with JIRA, but it's project-level, and it would be nice if it could be group-level since we have many small repos. :)

(I don't have an affiliation with Gitlab, I'm just super happy with the service.)

EDIT: typo

Thanks for your kind words for GitLab! Our JIRA support is pretty extensive https://docs.gitlab.com/ee/project_services/jira.html but extending it further is a priority. Felipe Artur is working on this full time. Consider creating an issue for group level integration, it sounds interesting.

Thanks for the comment! Group-level integration with JIRA is a nice idea. I've created an issue for this [1]. If you would like to give us more details on how we could achieve this, or give us some insights of your use cases, please comment in this issue!

[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/25867

Hi! Thanks for your kindness =)

We have a couple of open issues about integration with multiple JIRA projects: https://gitlab.com/gitlab-org/gitlab-ce/issues/25541 and https://gitlab.com/gitlab-org/gitlab-ce/issues/25758. Having group level integration can be a good solution for these requests. We will talk about it on those issues feel free to join the discussion.

Full disclosure, I am a Codeship employee that helps onboard new customers for our Docker support.

That said, our (Codeship) Docker support is the most "Docker native" on the market, in my opinion. We build your containers, by default, using a Compose-based syntax and all commands are natively executed by your containers. There's no interacting with a Docker host or running explicit Docker commands at all.

We don't offer self-hosting but we do have a local CLI that lets you run and debug your process locally with parity to your remote builds.

Reply on news.ycombinator.com