I recently got rid of my personal gitlab because it's too painful to operate. I only need a simple ssh user with a directory for my own purposes.
Gitlab is only necessary at work where we are an entire team using it.
I've always avoided the docker setup because I want control of where my database is and such details.
But yeah all I see when I look at the install instructions are the same steps as gitlab requires, unless you use Docker.
It would be possible for them to make a simpler package for simple users where they'd use sqlite for example. This can easily be upgraded to Postgres/MariaDB.
I like the ROOT setting because that means I can easily adopt gogs on my existing personal git server which simply uses a gitrepos directory in a home directory on a closet server.
So hypothetically were they to use a default database setting, and a default ROOT setting, you could have a working gogs setup with just two package manager commands, one to add the repo and one to install the package. That's painless!
Advanced step can be to create a mysql database and import your sqlite data.
I would love to share this little piece of information about GitLab installation with everyone.
Since there was a little confusion mentioning GitLab installation, I would love to clarify that our installation page [1] offers many different approaches. Before the installation process, please make sure that you read our Installation doc [2].
The Omnibus package may be the best choice installation since it is quicker to install, easier to upgrade, and it contains features to enhance reliability not found in other methods [2].
[1] https://about.gitlab.com/install/
[2] https://docs.gitlab.com/ee/install/
[3] Other official installation methods are via Docker, Kubernetes, Google Cloud Platform etc.
I think the most complicated thing I do with it is have a script which writes my LDAP server's credentials into it automatically.
But as soon as you start touching HA, you have to unbuckle all of it's components, and that's where it becomes a real, real pain. Because gitlab does not assume you will do this and starts _freaking_ out when it tries to start something which doesn't exist on the local system.
It takes a long time to find all the dials and triggers to turn local starting off, and even then you basically have a full omnibus installation sitting on each of your nodes, because even if features are turned off they sometimes need some part of the code for the feature.
At this point upgrading anything is not just a tedious process, it's also error-prone and time consuming. Take every web-node down, upgrade the local packages on the web node you use to upgrade the database, then do the db migrations, then you go around upgrading everything else to the latest version, then you can slowly bring everything online and hope that it works.
Don't event get me started on extending it's authentication system.
You can open issues about specific complaints in [1] and [2].
Funny enough I believe I finally figured it out, after years! It was hanging on mail notification jobs because the MTA wasn't properly setup. Once the MTA was fixed sidekiq was working better and I was also receiving mail notifications.
Even so, syncing with AD I get internal names like shortname@addomain.local and most users don't update their profile. Thankfully the MTA just queues them and discards them without blocking sidekiq.
I've worked a lot with async jobs in Python using both RMQ and rq, I don't see why sidekiq should be such an issue. I've never had issues like that myself in my own projects.
Also felt that it was hard to manage compared to my own experiences with job management in Python. Adding to the frustration was having to understand a (to me) foreign language like Ruby. Something I never wanted to learn and avoided successfully. I ended up having to write a little bit of code that could kill sidekiq jobs because I couldn't figure out how to do it through any interface provided by Gitlab.