6 ms·

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 th

by knocte 10y ago

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.

tzaman 10y ago
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!
- sytse 10y ago
  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.html 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-registry/ https://about.gitlab.com/2016/05/23/gitlab-container-registr...
  - tzaman 10y ago
    Thanks for clarification - I'll definitely have a look :)
  - aeharding 10y ago
    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
    - sytse 10y ago
      Thanks for your kind words for GitLab! Our JIRA support is pretty extensive https://docs.gitlab.com/ee/project_services/jira.html 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.
    - robinhood 10y ago
      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 https://gitlab.com/gitlab-org/gitlab-ce/issues/25867
    - Felipe_Artur 10y ago
      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 https://gitlab.com/gitlab-org/gitlab-ce/issues/25541 and https://gitlab.com/gitlab-org/gitlab-ce/issues/25758 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.
- ethangj 10y ago
  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.
sytse 10y ago
Thanks for your kind words about GitLab. We're working hard on making GitLab.com faster, see https://gitlab.com/gitlab-org/gitaly/issues/ 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 https://about.gitlab.com/products/#comparison For an intro to Gitlab CI see https://about.gitlab.com/gitlab-ci/ https://about.gitlab.com/gitlab-ci/
dom0 10y ago
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.
- aeharding 10y ago
  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 https://docs.gitlab.com/runner/install/linux-repository.html
  - drdaeman 10y ago
    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.
    - sytse 10y ago
      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/ https://about.gitlab.com/installation/
- pselbert 10y ago
  > 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.
sambe 10y ago
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!

by knocte 10y ago

tzaman 10y ago

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!

sytse 10y ago
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.html 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-registry/ https://about.gitlab.com/2016/05/23/gitlab-container-registr...
- tzaman 10y ago
  Thanks for clarification - I'll definitely have a look :)
- aeharding 10y ago
  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
  - sytse 10y ago
    Thanks for your kind words for GitLab! Our JIRA support is pretty extensive https://docs.gitlab.com/ee/project_services/jira.html 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.
  - robinhood 10y ago
    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 https://gitlab.com/gitlab-org/gitlab-ce/issues/25867
  - Felipe_Artur 10y ago
    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 https://gitlab.com/gitlab-org/gitlab-ce/issues/25541 and https://gitlab.com/gitlab-org/gitlab-ce/issues/25758 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.
ethangj 10y ago
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.

sytse 10y ago

Thanks for your kind words about GitLab. We're working hard on making GitLab.com faster, see https://gitlab.com/gitlab-org/gitaly/issues/ 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 https://about.gitlab.com/products/#comparison For an intro to Gitlab CI see https://about.gitlab.com/gitlab-ci/ https://about.gitlab.com/gitlab-ci/

dom0 10y ago

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.

aeharding 10y ago
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 https://docs.gitlab.com/runner/install/linux-repository.html
- drdaeman 10y ago
  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.
  - sytse 10y ago
    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/ https://about.gitlab.com/installation/
pselbert 10y ago
> 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.

sambe 10y ago

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!