Kontroler: "DogFood" Testing

Kontroler my latest project that’s all about workflows and now self-testing! At its core, it’s a workflow orchestration tool, but what sets it apart is how with some additional components we can being to "dogfood" the tool. In plain terms, it uses its own features to test its functionality, proving it works while continually improving itself. Pretty neat, right?

Why aim for Self-Testing the tool?

I’ve always loved automation. It’s the secret sauce behind smooth CI pipelines, quick deployments, and less developer frustration. But when I set out to build Kontroler, I didn’t just want another tool that runs workflows. I wanted something that could prove it works — without relying on third-party testing tools.

That’s where self-testing came in. It’s like giving the tool a built-in stress test. If it can handle its own workflows without breaking, you know it has some foundation we can build upon. Watching it tackle quality control all on its own is both practical and kind of satisfying.

How Kontroler Tests Itself

To get Kontroler to self-test it required building some additional components. Two new services:

• A GitHub webhook listener to handling the incoming webhooks, read the infra directory and create both the Dag & DagRun.

• A Kontroler webhook listener to handling outgoing events from kontroler. Kontroler can provide webhooks to listen for when a task ends, providing information such as the status and the task it links to.

As mentioned, a new directory was added to the repo called .kontrolerci that contains some yaml files that determine how the Dag/CI pipeline will work. Here is an example of how to create a simple go builder:

build-server:
  image: golang:1.23.5-bullseye
  script: |
    echo "Navigating to server directory"
    cd server
    go mod tidy
    echo "Building server application"
    go build -o main cmd/main.go

If you want to see the full directory go to the repo at: https://github.com/GreedyKomodoDragon/Kontroler

What does it test?

Currently the pipeline covers:

• Installing Packages (npm, Go)
• Linting (Go)
• Unit testing

These tests help provide confidence in the system, and the fact the CI pipeline ran also provides a end to end test to show Kontroler is correctly allocating tasks and outputing the webhooks when required.

This is what it looks like within Github's UI:

The Fun (and Frustration) of Dogfooding

The first time it managed to get the whole way through the pipeline was a magically moment, seeing all those green ticks was more satisfying than I imagined it would be. Kontroler was really being used, even if it was just myself using it.

But, let’s be real, building something that tests itself isn’t sunshine and rainbows. There were so many issues and bugs I came across. Like trying to understanding why my client was no longer authenticating to kontroler, or why if I put something into the tmp folder the pods started exiting with errors.

But by dogfooding the tool I can now see the flaws in the tool and begin to fix them!

What’s Next for Kontroler?

There are so many things to fix & add thanks to dogfooding the tool, we are aiming to:

• Allow podTemplate to be overidden at runtime, adds more flexibility to the tool which a workflow like a CI pipeline needs
• Provide functionality to create PVCs within the DagRun CRD

We will continue to "dogfood" the tool and use it to further productionize the tool!