It is also worth nothing that over time, the omnibus-gitlab package has benefited greatly from being used to deploy to GitLab.com. As we migrate more of the workloads into kubernetes using the charts, we expect to see some of the same benefits and insights there. See our handbook for more details on how we use dogfooding: https://about.gitlab.com/handbook/engineering/#dogfooding
Every case of dogfooding brings tremendous benefits to the depth and quality of your offering, no doubt about it and these improvements are very much welcome. Issue I have is not with dynamic, but with the current state of affairs, were wide spectre of features are presented as ready, yet they are not as high quality as Gitlab marketing.
(GitLab employee) thank you so much for the feedback! We agree that a lot of our features aren't as polished as they seem to be presented, which is why we hope the Maturity page adds more transparency.
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.
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.
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]
