For some time now, I've been really interested in devops, making development itself almost a side-hobby. And since I'm self hosting a Gitlab instance, and I have a Kubernetes cluster, and many containerized projects, and not enough nerves and time to always manually deploy stuff when I update them (and we can go on with the reasons) I decided to look into Gitlab's integrations.
Granted - since then I have learned a lot of new stuff which made this transition to using Gitlab agent much, much easier.
So I've been playing aroun with this agent thing, deployed one for a private project of mine and it was just great - until I learned that, when using the easy way of installing it on your cluster grants the agent cluster wide administrative permissions! And of course I don't want that because I'm using my cluster - although this approach is an "anti-pattern" - for multiple projects, each with their own namespace.
So I went to read the f*cking manual and learned that there's an alternative, advanced way of doing things. Basically constumizing the manifests to your needs which is all fine and well, but I wanted a simple, fast, environment variable-based solution - so I made gitlab-agent-namespaced.
Using the gitlab-agent-namespaced project you can create a new namespace for your project, create the neccesary role, service account and deploy the Gitlab agent - all restricted to the namespace you want.
Note that the namespace can already exist, and in case you created it imperatively you will get just a warning telling you that it already exists, it doesn't have the
last-applied-configuration annotation and that it will be now added automatically.
You can aquire the agent token when adding a new agent in Gitlab.
Keep in mind that this
GL_ENDPOINT value is pointing to my self hosted Gitlab. Change the hostname to your own Gitlab instance when installing. If you are using Gitlab.com you should use