Hey, the project used in this tutorial got superseded by a new helm-based one.
You can still follow this post, just keep in mind that you do not need the tools described in usage, instead you only need helm.

# Intro

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, I have a Kubernetes cluster, many containerized projects, and not enough nerves and time to always manually deploy stuff when I update them (we can go on with the reasons) I decided to look into Gitlab's integrations - more specifically, deploying apps to a k8s cluster.

Last time I did that, when the only way to connect the two was "the certificate way", it turned out to be a mess and the project went belly-up after a few weeks of me pulling my hair out.

Granted - since then I have learned a lot of new stuff which made this transition to using Gitlab agent much, much easier.

# The problem

So I've been playing around 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, the manifests grant 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 restricted to 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.

# The solution

Using the gitlab-agent-namespaced project you can create a new namespace for your project, create the necessary 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.

# Usage

So how do we deploy it? It's rather simple: ensure you have envsubst and kubectl installed, kustomize is already built into kubectl.