<rant>
OK, so however thought up the structure of the #Gitlab 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.
@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).
https://codeberg.org/johanneskastl/gitlab_vagrant_libvirt_ansible
https://codeberg.org/johanneskastl/gitlab_and_runner_vagrant_libvirt_ansible
@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!