[bartvanH]

I really like the core of gitlab. It's a really good git hosting system that is easy to maintain and work with. My self hosted instance has broken only twice in the last 1.5 years and it was always because of an upgrade and it was always easily fixed.

But now i have to say i'm afraid gitlab is getting bloated. Why not keep the core product as a seperate thing from things like CI? a simple plugin style system would be enough for it to not feel like bloat but feel like extra options.

[roblabla]

I just updated the NixOS gitlab package from 8 to 9[0]. It was a nightmarish experience. There are 5 microservices :

- gitlab (the core)

- gitlab-sidekiq (a work queue)

- gitlab-workhorse (provides the frontend)

- gitaly (a git wrapper that caches stuff)

- gitlab-shell (a shell spawned when doing your git clone)

Those are written in either go or ruby. Sometimes mixing the two in the same repository. In the main gitlab repo, there is also some unvendored js dependencies for the frontend, necessitating to jump through some more hoops.

Gitlab has a bunch of hardcoded paths to logfiles and config files. Some config files are toml, others are yaml. Different services need different configs, sometimes duplicating the config entries in a different format.

I love gitlab as a product. But as a sysadmin, it's one of the worst thing I've ever had to deploy.

[0]: Well, it's not pulled there, but it's at https://github.com/NixOS/nixpkgs/pull/27159 if you're interested.

[ibaum]

Thanks for the feedback. I'm on the build team here at GitLab, and we try and keep installation as easy as we can, but GitLab is a complicated application.

One of the benefits of the omnibus package, is that all configuration is done through a central gitlab.rb file. So the different configuration formats for the individual services is not noticeable to the administrator. Unfortunately, this doesn't necessarily translate to source installations.

We try and provide good documentation for building from source when our omnibus package or docker image isn't an option: https://docs.gitlab.com/ce/install/installation.html. Any feedback on issues you might have following this guide is welcome. I don't know that we can fix the different configuration formats, but we should be able to fix hardcoded paths. Any examples you could provide would be appreciated.

We do provide docker images for those on operating systems we do not support. https://docs.gitlab.com/omnibus/docker/. If you're just looking to run the latest version, this might be the easiest way for you to proceed.

[roblabla]

We have a patch for gitlab in nixos that fixes a lot of our problems. I don't know why we never tried to upstream it, but I guess it's just that nobody bothered. I'll try cleaning it up and upstreaming it when I have some time.

For the omnibus, I'll try looking at how it works, see if it fits our needs better. But I suppose gitaly, which is written in go, still has its own configuration elsewhere, in which you have to replicate the storage list ? That's the sort of thing that I find sort of annoying. It's not a huge issue, but having to manage a bunch of configs, making sure they're all synchronized and up to date sucks as a user experience.

I do have to say, your upgrade guides are very nice and have been helpful when upgrading our instance :).

As far as docker and other things go, I considered it while fighting to get gitlab 9 to work on bare nixos. But the thing is, I manage all my services through nixos, having a central place for all my configuration. This[0] is my configuration (well, a very old one). Everything is in one place, and everything can cross-reference each-other. See my firewall for instance[1], that cross-references various other service's configuration to get their port.

With docker, this is much harder to achieve.

[0]: https://gist.github.com/roblabla/8d1555ceb202eddb1b77

[1]: https://gist.github.com/roblabla/8d1555ceb202eddb1b77#file-c...

[ibaum]

The omnibus package is similar to the nixos way of things, except focused on one application rather than the whole system. Once the package is installed, it uses a configuration file, and a set of Chef cookbooks/recipes[0] to configure the individual components.

So yes, Gitaly does come with it's own configuration file that needs to be managed. It does use the same paths as the main gitlab-rails application, so our cookbook has a method to convert the configuration of one to the other[1]

[0]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil...

[1]: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/fil...

[FTA]

This was my same experience. I spent three solid work days trying to install it from source since it's on a server with other services and their default nginx etc. setup couldn't work. All the different microservices made installing from source very difficult. I ended up finally giving up and using the black box omnibus installation and fiddling with the configuration file for a while.

It works now but I can't hack the source to make custom improvements, so it ends up not being as open source as I would have hoped. There's one particular issue in trying to push that results from being on a URL subpath (http://.../gitlab). I can't fix it myself because of that.

Don't get me wrong--it's a good program and has worked for the team I support. But click and deploy is not useful for people who don't have bare bones servers they can spin up and instead have to work with shared servers.

[dijit]

I gave up and ran a docker container with reverse nginx vhost proxy to the docker port.

[sytse]

Please use the official Omnibus packages to ensure that upgrades are less likely to break.

I think we use toml for the Runner since it is written in Go and should be deployed on another server. The rest is mostly in yml files although we trying to move as much as possible to the UI to make it more user friendly.

[eropple]

> Please use the official Omnibus packages to ensure that upgrades are less likely to break.

That would be almost precisely against the whole idea of NixOS.

[EddieRingle]

> I think we use toml for the Runner since it is written in Go and should be deployed on another server.

Couldn't you just parse YAML in Go, or TOML in Ruby? (Or why not give the option of multiple formats?)

[whatnotests]

This is the kind of software one expects from a team who has never seen how it's supposed to work in real life.

[cmatija]

GitLab is envisioned as a platform for the full SDLC - from idea to production [1][2].

If you don't want to use the CI, it shouldn't get in your way. We'd love to hear any specific suggestions you might have, since we're always looking to improve. You can open an issue about them in [3] if you want.

[1] - https://about.gitlab.com/handbook/product/i2p-demo/

[2] - https://about.gitlab.com/direction/#scope

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

[mikepurvis]

As GitLab user, I think the concern for me is split focus. For everywhere there's a tightly integrated built-in tool (issues, CI, container registry, etc), there also needs to be a separate, parallel effort to create, maintain, and document a sufficiently rich plugin interface that a third party can create a similarly tightly integrated experience when plugging in something external.

Basically, they build the hooks but aren't dogfooding any of it, since their own integrations don't have to.

And speaking from the perspective of someone using GitLab with Jira and Jenkins, it just isn't the same. Is that necessarily because of problems with the interface or is it just those specific plugins? I don't actually know.

[brodock]

GitLab CI started as a separate project, but team saw more benefits from integrating into a single product as it's much easier to provide tightly integration without the overhead of communication and APIs. There are places in the workflow that can't just support a hook for an external integration.

While CI is integrated, it does not force you to use it, and there are ways to integrate with external solutions.

While CI is part of the same product, you don't run the tests in the same machine, so you still need to provide the workers in additional ones or use the autoscalling mechanisms and have it bootstrap machines in the cloud as needed.

So what I mean here is that while it is part of the product, it's mostly the "frontend" and the "APIs", the heavyload part of running it is totally optional.

[mikepurvis]

Sure, and I get all that— it definitely makes things easier for the creators and maintainers of the software, and it's easier to deploy it too, so it's a win for small shops who aren't yet committed to a lot of other tools, or are fine with being committed to an "omakase" experience where everything is okay and nothing is best-of-breed.

But there are definitely some customers who are sidelined by this approach. Atlassian is pretty committed to tools that talk to each other with documented APIs (Jira, Confluence, Bamboo, Bitbucket/Stash), and for large organizations, that's often a better fit.

[brodock]

It serves different business purposes. Atlassian make money by selling each individual product license. Also there is a reason why they are not part of a single unified platform, some of then were aquisitions, etc.

There are many players doing "unix" application, and very few trying to build a suite. You need to pick your fights.

[adrianN]

I would prefer different tools for different stages in the software lifecycle that can be changed independently from each other because they only talk in simple protocols. Everything-Included tools converge to IBM or SAP products that do nothing really well and trap you into their solution because the integration is too tight.

[sytse]

We hear your concern about GitLab getting bloated. We first made GitLab CI as a separate application. When Kamil (CI lead) proposed to Dmitriy (co-founder CTO) to add CI to GitLab itself he said that was a bad idea, we need sharp tools. After Dmitriy became convinced and when they proposed it to me (CEO) I had the same response: http://redmonk.com/jgovernor/2017/06/21/how-gitlab-abandoned...

But when we integrated it the sum was more than the parts. The benefit of deep integration and not having to switch applications are becoming more apparent to us. It is hard to articulate why the same can't be done with plugins, the video in the article is maybe a good start.

Review Apps, changes metrics in the merge request, the container registry being aware of your permissions. All this can be done with plugins. But having it in one applications is so much easier to set up, upgrade, and use day to day.

[green7ea]

I also really like Gitlab but the self-hosted instance I manage broke twice in the last month due to faulty updates :-/.

First, the automatic notification e-mails stopped working until I did another upgrade. A later update broke issue merging: merging one merge request closed all work requests (event the ones with WIP).

If you also consider the sudden removal of the backlog from the issue board a while ago (they added it back since), I'm now afraid to update our Gitlab instance.

This is very unfortunate because Gitlab is a very nice and useful tool but if QA doesn't improve, it will be very difficult to prevent a migration. These problems are show stoppers for us.

[Outpox]

My Gitlab instance broke 3 times in 5 months, and my questions/issues haven't been answered. I had to manage to backup my data, fully uninstall Gitlab and reinstall it. I then hosted it on a dedicated server using docker and it has been running much better since then.

[green7ea]

We run Gitlab in an LXD container with an Omnibus install. Everything works pretty well but those issues were caused by regressions in updates. There were new updates fixing those regressions within a few days but it still caused us quite a few headaches.