Hacker News new | past | comments | ask | show | jobs | submit login

> Also like most people that I've spoken to, we're not interested in gitlab-ci at all

Consider me part of the crowd that is very interested. Travis is atrociously bad. Jenkins I've heard some good things about but I have mostly negative experiences with it. Alternatives are needed. And something like gitlab would sorely lack if it didn't have CI integration.




We are definitely interested as well. - Open-source (check) - Self-hosted (check) - Integrates with GitLab (check)

We do run Jenkins currently for some projects, but nobody is really happy with it. Sure, it gets the job done, but not the easiest software to work with.


Cool, we hope that GitLab CI will be very usable. Due to the integration it will be easy to set up for a project. We're aiming for zero config: 'just add a .gitlab-ci.yml file'. And the yml file http://doc.gitlab.com/ci/yaml/README.html makes it very easy to collaborate on how a project should be tested https://about.gitlab.com/2015/05/06/why-were-replacing-gitla...


How are you using Jenkins? I've found that it works well as long as you just have Jenkins call build, test, deploy, package scripts.

The advantage being that you can use the same scripts during development.


That's how we do it. EnvInject and shell scripts. But I'm starting to think Jenkins is a bit much to run the equivalent of "HOST=somewhere NODE_ENV=production ./script/deploy" and ping a slack channel


Could you expand on what you hate about Travis? I'm in the process of picking a CI system and haven't found too many negatives about Travis yet.


I was using travis-ci for a long time. One day my credit card died during their billing cycle. They emailed overdue receipts to colaborators on all my travis-ci repos. All clients, all devs, everyone. Thats breach of information, I don't want client1 to know who all are employed at client2's firm.

Ok, fine, bugs exists in software. I emailed them saying that 'Guys, you should email only repo owner when payment fails, no everyone on the team". No response. I considered that lack of support and moved to circleci.


Admittedly, when self-hosted some of these may go away, but here are a few that come to mind.

* General awfulness when it comes to packages. Outdated packages. Nonstandard packages. Ubuntu, instead of debian + testing, is a terrible choice for a CI.

* Horrible support for multilingual builds. God forbid if you have Python 3 scripts in your go project.

* With github, force-pushing during a build causes the build to error and travis can't detect that

* Lots of papercut issues in the UI

* There's always something when setting it up on a project that makes me end up fighting with it and figuring out crazy workarounds for it for several hours.

There's a lot more, though most of them have to do with point #1 and their choice of Ubuntu as a platform. I don't remember the rest.


I just went through the same process for my team, settled on CircleCI because the pricing structure fit our needs. We're still newish to CI in general so we might be wearing blinders but it's fit our needs so far.


I've used Travis for 2 years and loved them. YMMV I guess.


A bit shitty of me to recommend an alternative to Gitlab on this post, but have a look at circleci - it's very impressive.


I've been happy with http://www.go.cd/


Why is Travis so bad? Ever tried CircleCI?


> Ever tried CircleCI?

I have not. It doesn't look to be open source though, so not self-hostable - my interest stops at that point.


Go.CD maybe? http://www.go.cd/


CircleCI is still missing crazy important features like: building downstream dependencies when libraries change and scheduled builds.

Until it gets basic features like that, Jenkins it is.


FYI GitLab CI will introduce a build trigger API with 8.0




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: