I found the operation of on-prem GitLab to be a bit of a PITA back then, has that changed? There was a whole bunch of rake tasks and junk you needed to run to upgrade and it required a shutdown of the system.
(Source: work at GitLab, and I wouldn't If we had to manage the infra by hand vs. omnibus/k8s)
I more recently used Gitlab on Ubuntu using their omnibus package for Ubuntu and the upgraded over multiple versions to get onto a later version of Gitlab. The upgrade process was a lot smoother (no fighting to build gems on SmartOS and patching all over the show to get gems and other dependencies to compile).
I also did a MySQL to Postgresql migration. You have a bit of downtime with the process which chef sorts things out post upgrade of the omnibus package. I did turn the unicorns and disabled ssh logins while I was upgrading the omnibus package just incase something went wrong during the upgrade.
We're upgrading two or three times a month, and I don't remember having had any issue just letting it update itself for at least a year.
Gitlab's downtime when upgrading the docker image is about 1 - 3 minutes every time, which hasn't been an issue for us (and otherwise I'd just schedule it for midnight)
My team of devs doesn't have a dedicated sysadmin.
To troubleshoot your problem smoothly, I'd advise not to modify your GitLab instance intentionally, for instance, applying own custom patch, changing database schema, etc.
I previously managed Atlassian instances and I dreaded ever touching the servers.
GitLab def has there shit together in this regard.
edit: I forgot, when issue, their docker container uses tmp memory that never seems to free itself. I occasionally (once a year) have to rm and recreate the container, which isn't a huge deal for me.
I'm not sure what it's doing, but at least it's an easy fix.
[0] https://gitlab.com/gitlab-org/gitlab-runner/merge_requests/1...
Thanks for bringing this up I hadn't seen your contribution! I think this is a great idea. I know the technical team has been overwhelmed with community contributions as of late - which is a good problem to have but one that we're still solving. I'm going to try and shepherd this one along myself. If you want you can reach out to me on Twitter @olearycrew or my email is boleary [at] gitlab.
@boleary-gl have you all considered having someone dedicate time each day / week to prioritizing community issues?
Oh jolly good! This exact feature was something I've thought about as useful for microservice stacks where you need interconnected background services for integration testing. Very nice of you to contribute this feature, thanks! Hopefully this will be merged at some point.
Looking through (browsing repositories) there is almost NO adoption to gitlab.
I don't know the figures, but the teams I encounter using Gitlab are self-hosting, you aren't going to be able to browse their (private) repos.
We used to have a Explore link on our homepage to https://gitlab.com/explore because HN asked for it but it got dropped.
I've asked to reinstate it in https://gitlab.com/gitlab-com/www-gitlab-com/issues/3713
Gitlab Cloud v Github Cloud. Github cloud is easier to grok, and get started versus gitlab, adoption on github is very visible, and immediate from first landing.
Gitlab On Premise v Github Enterprise. Gitlab wins in offering (open source, and complete ci/cd). However, I would argue that the marketing is much stronger with Github. Github has a streamlined message which you can consume easily and then once you're in you get deeper into the meaning of.
This is what I am referring to. Model or not, it's something that is a barrier to entry.
At work we are using Atlassian products, they would be so efficiently replaced by just Gitlab
Maybe it was a regression in an old version?
I've found this invaluable for working solo or in group projects.
However, they are just using the same ruby package that Github uses to render the org-mode to HTML... unfortunately it is far from perfect.
Still, it's MUCH better than the go version in Gogs, so there's that.
Not sure if it wouldn't be just as well to run Nexus OSS instead though? https://www.sonatype.com/nexus-repository-oss
You might not get as tight of integration as Gitlab will provide, but the Nexus OSS repository provides some nice features in terms of cleaning up old artifacts, some disk usage policies, etc.
