Hacker News Reader

Comment by yarper | Hacker News Reader

Maybe with this 4M they can stop producing workflow crushing bugs. I'm getting a bit tired of explaining to my boss why first he can't search the code because our repo is too big, then search doesn't work in firefox, then when he gets through the diff/file is too large (we've only recently seen the syntax highlighting start to work too).

Then after someone does the work, then they can't assign the MR because of glitchy privs!

If anyone is reading this at gitlab, please don't take this personally. I wouldn't leave gitlab, I just need the core 80% of the functionality to work flawlessly, and my upgrades to work without half of my team moaning at me for having faith that this upgrade will be the gold edition we need.

Also like most people that I've spoken to, we're not interested in gitlab-ci at all (we already have a ton of buildscripts in jenkins). If we didn't like jenkins we'd be using stash/bamboo right now.

View on HN

I'm sorry to hear you're workflow crushing bugs on updates. We'll certainly use the money to hire more developers and service engineers https://about.gitlab.com/jobs/

Although GitLab moves very fast and there always are regressions I thought we are getting much better at releasing patches for all regressions. I'm sorry to hear your experience is different.

How large is your repo? Code search shells out to git and that should be very performant. Are the repositories stored the same server as the application runs on?

Syntax highlighting switched from pygments to rouge, ensuring we don't have to ship Python anymore.

I didn't hear about the problem of assigning the MR, can you link to an issue for that?

We want GitLab to work flawlessly when you upgrade. And at the end of each monthly release cycle the patched version should not contain any known problems. We're working hard in the regression issues to make it so https://gitlab.com/gitlab-org/gitlab-ce/issues/1990 and https://gitlab.com/gitlab-org/gitlab-ce/issues/2297

We think that the CI configuration should be stored in the repository and that Travis and GitLab CI are the future instead of Jenkins and Bamboo.

We understand that not everyone will use GitLab CI (most enterprises are using Jenkins) but already have many organizations (including some very large ones) using GitLab CI in production. GitLab CI will undergo massive improvements after integrating it into GitLab itself in 8.0 so you might want to stick with Jenkins if you don't want to be surprised. But we recommend anyone to give GitLab CI as spin while we keep adding features. You'll be happy to know that GitLab 8.1 will ship with a commit status API that makes integrations with third party CI tools easier.

You've gotta look at it this way - when github updates do I even notice? Have you ever had a bug that stopped you working on github? I personally use github all the time and have never seen a bug on it. I trust it completely (well.. tech wise).

Our repository is a few million lines, maybe 20,000 commits. The search works fine now it has been changed to call out to git properly (aside from the js searchbox thing in ff). Repositories are stored on the same server. I'm not going to dig up all the issue numbers and turn this into a support request, I am involved in reporting these and commenting on them @ gitlab.com.

The syntax highlighting updates have been very well received, but I mean gitlab was shipped with syntax highlighting that doesn't work properly with Java code. Not exactly a unusual lang. And I guess that's where my rant was going - you can't ship crap like that, you should be shipping with 0 known bugs. Every time gitlab ships a bug like this, I take a knock in the office on your behalf and that's why I'm so openly annoyed.

Perhaps you could do a LTR or open a beta programme for early adopters?

I'm glad to hear most things are working now. We're hiring to put more eyes on the open issues on GitLab.com. If you want a more stable GitLab upgrade to a new minor release on the 21th of every month. At that time all the patches should have landed. We strive to fix all known regressions. If they want to use the bleeding edge people can use our release candidates. Or run master, like we do on our internal server.

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

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

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.

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.

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.

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

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

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

Reply on news.ycombinator.com