digitalcourage.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Diese Instanz wird betrieben von Digitalcourage e.V. für die Allgemeinheit. Damit wir das nachhaltig tun können, erheben wir einen jährlichen Vorausbeitrag von 1€/Monat per SEPA-Lastschrifteinzug.

Server stats:

823
active users

<rant>
OK, so however thought up the structure of the helm chart was ... creative, to put it politely.

The chart itself has dependencies, as is common with helm charts.
But it also has a charts directory, which contains 5 other charts. Including one called gitlab.
Which again has a charts directory as well as dependencies.

So, depending on which chart you want to configure, it might be chart-name.something or gitlab.chart-name.something. Oh, they also use global.something or global.chart-name.something.

And as this is not creative enough, some charts are installed if chart-name.install is true. For some it is chart-name.enabled...

But help is near, there is an operator, that does the heavy lifting for you. Oh wait, it uses the values from the helm chart of its CRD...
</rant>

In other words, I think I have a working Gitlab-on-k3s setup using Vagrant. In case you want to try for yourself...

Needs a LOT of cleanup, but once that is done, I'll publish to the usual places (codeberg, github).

@johanneskastl imo GitLab is just a bit too complex, for many org. I had a client with on-premise rpm based installation. Every upgrade was a pain, as they are on 15.x migration docker-based installation is a challenge 🙂
Of small org I feel much better with #forgejo or #onedev.

Johannes Kastl

@jwolynko When it comes to on-prem, GitLab still seems to be the preferred solution (GitHub enterprise seems to be deprecated, thank the universe for that). I personally am running Forgejo wherever possible.

But most of the customers I know do run some form of GitLab. And I wanted to make sure I had a working test setup, whenever I need one. Currently I wanted to do some testing for GitLab runners on Kubernetes.

The package based ones are pretty simple to setup (not talking about maintenance, of course).

codeberg.org/johanneskastl/git
codeberg.org/johanneskastl/git

Codeberg.orggitlab_vagrant_libvirt_ansibleVagrant-libvirt setup with a VM that is running a Gitlab instance

@johanneskastl thanks for sharing I will save it just in case!
And you’re right in case of real enterprise ready solution GitLab is very popular solution.
I had some projects 2/3 years ago with GitLab workers on OpenShift, beside the privileges challenge it way very smooth, so I believe Kubernetes version will be much more flexible! Good luck then!