Recent searches
Search options
<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).
Here you are: Vagrant-Setup with Ansible deploying k3s and GitLab inside k3s.
https://codeberg.org/johanneskastl/gitlab_on_k3s_vagrant_libvirt_ansible
https://github.com/johanneskastl/gitlab_on_k3s_vagrant_libvirt_ansible
Currently without the Runner, that comes next.
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.