<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>

#GitLab #devops #helm #kubernetes #why

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).

gitlab_on_k3s_vagrant_libvirt_ansible

Vagrant-libvirt setup that creates a VM with k3s and installs GitLab in the cluster

Codeberg.org

OK, I managed to improve lots of things in those setups and make the setup more reliable (even in case it takes really really long for everything to be up).

https://codeberg.org/johanneskastl/gitlab_on_k3s_vagrant_libvirt_ansible

Now with four branches, one for Gitlab installed via helm chart and one using the Gitlab Operator.
And each of them with and without a Gitlab Runner being installed into the cluster.

#GitLab #Kubernetes #k3s #devops #Ansible #vagrant #libvirt #hellyeah

gitlab_on_k3s_vagrant_libvirt_ansible

Vagrant-libvirt setup that creates a VM with k3s and installs GitLab in the cluster

Codeberg.org