Hacker News Reader

Comment by theunquietone | Hacker News Reader

Hey Paul - All great notes. We believe in a single solution from idea to production. More about that here: https://about.gitlab.com/direction/#scope

We hope to make it easy to go to a single place for everything needed for development from issue boards, CI, analytics, etc. The unified UX for this tool is key and we are hiring a great team to support that goal.

Later today we're having a live event to talk more about that vision and answer questions. https://page.gitlab.com/20160913_unveilingmasterplan_landing...

Again, love the notes and how you're thinking about this. Happy we are aligned!

Edit: Sorry! Removed the signature. Habit :)

View on HN

Makes for a tough pitch at an established shop with existing tools already in place.

We hope to create tools and resources to make that pitch and migration easier. Out of curiosity, what tools are you currently using?

We think it'll be a piece by piece migration versus all at once. In a perfect world, we have a tool for an all at once migration but perhaps that will come with time.

The problem with that approach is that you're limited by the quality of your weakest tool. Code review might be a strength, but if your CI tool is weak, that's what you'll be judged on. Integrations are a way to allow you to focus on what you do best and effectively outsource the rest. Ideally, the integration hooks would be well integrated, but I don't see an upside in trying to make a monolithic app in this market.

GitLab allows you to integrate with your existing tools if you please or require. But if you're fine using our tools (which are awesome, if you'd ask me), setup and cost will be zero.

I agree. It is essentially the same vision like the old ALM tools had. They were beaten by better more specialized tools following the unix philosophy: do one thing and do it well.

We've just opted for GitLab EE, the True-Up Licensing Model won us over, but also the promise of a working Jira Integration. That's still very limited and a pita to setup, even harder when you use atlassians hosted Jira. I don't want to buy GitLab Licenses for non-developers, especially as our Jira is connected to Zendesk, something which doesn't make sense to connect directly to GitLab.

We already have an extensive JIRA integration https://docs.gitlab.com/ee/project_services/jira.html But I agree we can do better. If something is unclear please email support@ our company domain to get help.

But I agree with your comment that we should extend the scope of the integration and make it work better with hosted JIRA. Our VP of Engineering is assigning someone to this task. Feel free to email stan@ company domain with a link to this comment and with what you need so we can have an engineer look into it.

Many companies use JIRA and it should work great with GitLab.

Apart from GitLab, we're mostly on Atlassian, and pretty strongly committed to JIRA and Confluence.

The CI solution in GitLab is inadequate for our needs; we require the flexibility and extensibility of Jenkins.

The review tool in GitLab has some significant gaps compared with standalone tools like ReviewBoard, and even compared with the one built into Bitbucket. It also has some baffling UX decisions, like the thumb/emoji buttons and the approve/merge buttons which appear in the exact same location as each other. Seriously, just scrap what you have and copy Bitbucket's review interface.

I'm not a gitlab employee or anything, but I'm curious: How is gitlab CI not flexible enough for you?

I mean, it basically just runs arbitrary docker containers. From my mostly amateur (when it comes to this, i'm a professional developer but I don't manage our CI system directly) point of view it seems like the gitlab CI is more flexible than jenkins not less.

As you indicated we hope that GitLab CI covers all use cases but we're always interested in learning things we can improve.

I added a comment to the parent, regarding test reporting. It's a showstopper for us.

The strong coupling between repos and CI jobs is a huge obstacle— for a multi-repo codebase, you need to have triggers that are outside of "a new commit has been pushed".

The reporting is a big problem too— Jenkins has plugins which format and report on JUnit-style reports, including displaying images or other assets generated by tests.

Configuration. The config needing to be committed to the repo is an issue. For many use cases including ours, it's way better to have the CI configuration stored centrally somewhere, and deployed using Jenkins Job Builder (or the various other similar tools which exist for Jenkins).

Executor control. Jenkins lets you do things like put N slots on a buildslave and then have a job occupy M of them, as well as controlling what jobs can run where, and what the priority of different jobs is. This is critical for ensuring overall sanity and efficiency in the pipeline.

Jenkins isn't perfect, but it happens to be a better fit for our needs, and these four factors are all a big part of that.

For multiple projects you can use build triggers https://docs.gitlab.com/ce/ci/triggers/README.html

We're considering parsing JUnit style tests https://gitlab.com/gitlab-org/gitlab-ce/issues/22098

We think storing the configuration in the repository makes it easier to collaborate on it (new branch is tested in the new way, master in the old way). Can you share your use case for this?

You can specify how many jobs you want GitLab Runner to run. It can even spin up more VMs automatically if you want that. You can bind jobs to runners with labels and specific runners https://docs.gitlab.com/ee/ci/runners/README.html

Our use-case is perhaps a bit unique, but ROS has a federated development model, meaning literally hundreds of repos. See the following file which maps repos to package names and versions:

https://github.com/ros/rosdistro/blob/master/indigo/distribu...

These get generated into thousands of jobs: http://build.ros.org/view/All/

It would be totally unrealistic to rev job configurations by making commits into the individual repos (and in the public open source case, actually impossible— the maintainers of that community build infrastructure don't have write access to many of the repos— it's equivalent to a Debian distro using DSC files to grab tarballs).

Thanks for the use case and the links. I must admit I never saw a 14234 line yaml configuration file before.

The jobs page is not loading for me right now.

I think that in general developers and the build engineers should both have commit access. But I see your dilemma and think we need to have a conversation to see what the possibilities are.

Great feedback, thanks!

This isn't exactly what you asked for, but we're seriously considering letting you "include" CI configuration from a central location.

https://gitlab.com/gitlab-org/gitlab-ce/issues/20868

As one example, GitLab CI does not have a good story with handling unit test failures from e.g. gradle.

You can choose to keep the build output from a failed build, which you can download as a zip file, unpack locally, and look at the reports. This user experience makes test reports mostly useless.

At the same time, they have test coverage badges, where test output is parsed to provide coverage. To me, that's really weird: You don't get proper access to test failures, but lots of work into test coverage.

(I have no knowledge of this, but I suspect that being a Ruby-shop, they have little experience with working with java projects, and therefore don't really understand how the toolchain works. This is all guesswork, though).

In the end, we cannot give up Jenkins. We need to know the result of our tests, and see the test output!

I totally agree that we can do better showing test output and we're working on that in https://gitlab.com/gitlab-org/gitlab-ce/issues/22098

most people probably miss JUnit-style reports.

Yep, see https://gitlab.com/gitlab-org/gitlab-ce/issues/22098 for the feature proposal.

Just running docker containers is basically a show stopper for certain use cases. Not every use case can even fit into a docker container. E.g. testing kernel modules.

Totally agree that not everything works on Docker. GitLab Runner works great on metal (Linux, OSX, Windows, RPi, etc.), no need to use Docker.

But it's a great pitch for a shop with limited ressources that currently has nothing.

We're currently moving to the Atlassian stack, from Bitbucket to Jira to Confluence. I really want to switch over to Gitlab reading this but the sunk cost is too huge already...

We want to play nice with existing tools. For example we're spending a lot of time improving our JIRA integration https://docs.gitlab.com/ee/project_services/jira.html

Most of our new users use only part of GitLab's functionality and we want to support that use case with extensive integrations and APIs.

Hey Sid, have you seen this: https://github.com/dka23/gitlab-github-proxy. I packaged it up and I already use it successfully with GitLab EE on-site: https://gitlab.com/harbottle/glghproxy-packager

The approach of including a GitHub -> GitLab API translation layer would allow GitLab to integrate with any application that can use GitHub. I've added this info to this ticket: https://gitlab.com/gitlab-org/gitlab-ce/issues/20418#note_15...

Big fan of GitLab btw, keep up the good work!

We want to play nice with established tools and give people the option to use them.

We have:

1. Extensive JIRA integration (and we're working on improving this) https://docs.gitlab.com/ee/project_services/jira.html

2. Jenkins support https://docs.gitlab.com/ee/integration/jenkins.html via our commit status API https://docs.gitlab.com/ee/api/commits.html

3. Slack integration https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/proj... and we're working on a Slack bot https://gitlab.com/gitlab-org/gitlab-ce/issues/20799

We realize that we should allow other tools to integrate well and want to open up as much as we can via API's.

Doesn't that kind of lend itself towards the walled garden philosophy?

Is there functionality being built-in to integrate with Gitlab instead of being forced to use everything Gitlab has to offer?

We want to be open to other applications, I've elaborated on this in https://news.ycombinator.com/item?id=12493537

"Please don't sign comments; they're already signed with your username. If other users want to learn more about you, they can click on it to see your profile. "

Applies to job title, too. Yes, even at companies who are special enough to get millions of dollars from VCs.

source: "In Comments" https://news.ycombinator.com/newsguidelines.html

I think it's important to take the bigger picture into account here. Letting us know who she is was a key part of that comment, since it's immediately relevant to the content.

Every rule has its exceptions. Sometimes it's nice to be able to quickly verify that the person answering a very specific comment about a specific company works at that company by avoiding the initial confusion or having to click anything. Let's not be overscrupulous.

Reply on news.ycombinator.com