Introduction
Hello!!!
So I decided to learn a bit more about CI/CD pipelines, and what better way to learn about them than to create your own!!! However, I also wanted to add my own spin to it: integrating it with Kubernetes and maybe Docker, to build a Kubernetes-native CI/CD tool. I'm not sure if the idea already exists out there, but I think it's worthwhile exploring for learning purposes.
Why the Name
The goal is to make use of what Kubernetes natively provides and build on top of it to create a more "Kubernetes-native" solution to CI/CD. Hence the first letter in KCX is Kubernetes.
Since this is a CI/CD tool, I reduced both into CX.
So in a sense, it's named Kubernetes CI/CD.
Why This DevLog
The goal behind this devlog is to:
- Share my progress
- Share any interesting ideas I run into while working on the tool
- Share my experience working with Go
- Engage with the community and listen for feedback on things I can improve, which is always welcome
What Will I Use to Build It?
Since many tools in the cloud space already use Go, I decided to follow their lead. This also helps me get more familiar with the language, since I've wanted to learn it for a while.
Any Progress?
So far I've started exploring a bit around the core ideas:
- Cloning a repository and executing a simple build script
- Creating a webhook and wiring it up with GitHub
I also tried out a distributed work queue setup — multiple workers wired to an API service through a RabbitMQ broker. After testing it, I decided to keep the tool minimal for now, with workers running as local threads rather than their own services. Eventually, I plan to have the tool support a distributed setup too.
Will I Use LLMs?
Not as of yet.
How Will These DevLogs Be Structured?
I'll aim for weekly. Whether I actually stick to that depends on what else I have going on — we'll see!
What's Next
Next up, I want to get a full local build running end-to-end, with support for both public and private repositories. I also want to test this across multiple platforms — GitLab, Codeberg, and GitHub — to make sure the tool isn't tied to just one ecosystem.
Top comments (0)