Building a Small Tekton GUI for the Features We Actually Need
Tekton has been at the core of our CI/CD infrastructure for several years. On OpenShift, however, we have never interacted with Tekton only through its APIs or command-line tools: the OpenShift web console provides a convenient graphical interface to inspect pipelines, understand their structure, start them with custom parameters and workspaces, and follow their execution.
As we started investigating a future Kubernetes platform independent from OpenShift, this raised a relatively small but important question: what happens to the user experience around our pipelines?
Tekton itself is portable. The OpenShift web console is not.
Tekton Dashboard Gets Us Most of the Way
The obvious first candidate was the upstream Tekton Dashboard. It already provides many of the features we need, especially around running pipelines: inspecting PipelineRuns and TaskRuns, reading logs, looking at the underlying resources and following an execution.
For those tasks, it works well.
Our problem was mostly around everything that happens before a run starts: some of our pipelines are also started manually by developers. In OpenShift, users can see the pipeline, fill in its parameters, configure the required workspaces and select the appropriate PersistentVolumeClaims without having to understand or create a PipelineRun manually.
There was also a smaller issue that had been bothering us for quite some time: most of our manually started pipelines use the same kind of workspace PVC. OpenShift lets users configure it each time, but we had no convenient way to provide our usual configuration as the default. It is a small piece of friction, but also exactly the kind that becomes annoying when repeated often enough. Since we were building our own interface, we finally had a place where we could encode that default while still allowing users to change the PVC size when necessary.
Building the Interface Around Our Workflow
We therefore decided to experiment with a small web application focused on the way we actually interact with pipelines.
The idea was not to reimplement Tekton itself. Kubernetes and Tekton remain the source of truth, while the application provides a more convenient entry point for the operations our users perform regularly. The current PoC can browse Pipelines and PipelineRuns across a configured set of namespaces and filter them to make larger environments easier to navigate.
For each Pipeline, it displays its parameters and a graphical representation of the task dependencies. A new PipelineRun can then be started directly from the interface, with editable parameters and workspace configuration.
For our usual workspace pattern, the storage class remains centrally managed while users can adjust the requested PVC size.
Existing PipelineRuns can also be used as the starting point for another execution. Their parameters are loaded back into the form, where they can be modified before rerunning the Pipeline. Metadata that matters to our workflows, such as the rd/author label, is preserved when creating the new run. Being able to rerun a pipeline while changing its parameters is actually a requirement that predates Tekton for us. It was already a missing convenience in our previous Jenkins-based workflow, so this was a good opportunity to finally address it properly rather than carry the limitation forward again.
The application also provides direct links to the corresponding execution in Tekton Dashboard. That reflects our current division of responsibilities: Tekton GUI is the entry point for finding, understanding and starting pipelines, while Tekton Dashboard continues to handle the execution details and logs that it already presents well. This boundary is pragmatic rather than strict. The result of the PoC has been good enough that we would not rule out bringing some of those existing capabilities into Tekton GUI in the future if having a single interface turns out to be more convenient.
The application is stateless and runs inside Kubernetes using a dedicated ServiceAccount and RBAC permissions. There is no additional database and no new state to synchronize: most of the current functionality is implemented directly against resources that already exist in the Kubernetes API. That simplicity was also important when deciding what to include in the first version.
One Innovation Day, with a Little Help from AI
The project started during one of our Innovation Days: once a month, our team reserves a day for activities outside normal project work: experimenting with technologies, investigating ideas that might improve our platform, or simply learning something new.
Tekton GUI was a good candidate: the problem was real, but not urgent enough to justify starting a conventional development project around it. There was one obvious constraint: one day is not much time to design and implement a web application.
This is where AI-assisted development made a considerable difference. We already understood both ends of the problem quite well: we knew how Tekton worked, how our Pipelines and PipelineRuns were structured, which Kubernetes resources we needed to interact with and what was missing from our current user experience. That allowed us to give the AI relatively precise requirements and, just as importantly, to recognize quickly when an implementation or assumption was wrong.
After roughly four to six hours of development, we already had a functional PoC covering most of the original requirements and we did not have to stop at the first working version. Within the same Innovation Day we could actually use it, identify bugs, fix them and iterate on parts of the interface that did not behave or look the way we wanted. The result was therefore not just a quickly generated mock-up, but an already refined PoC that was good enough to demonstrate to the rest of the team.
This is probably where AI had the largest impact: platform Engineering teams rarely suffer from a lack of ideas for small internal tools. What usually makes them difficult to justify is the surrounding implementation effort: frontend components, API integration, validation, error handling, deployment manifests and all the glue needed to turn a small idea into something usable. AI compressed a significant part of that overhead.
It did not decide which problem we had or what the correct workflow should be. Those were the parts where our existing knowledge of Tekton and our own CI/CD environment mattered most. In this case, AI worked particularly well because we knew where we were starting from and where we wanted to arrive.
That still meant reviewing the generated code, correcting assumptions and understanding what the application was doing, especially since it is allowed to create resources inside a Kubernetes cluster. But being able to move from an idea to a useful and already iterated PoC within a single Innovation Day changed the cost of trying the idea considerably.
And yes, seeing that happen in a few hours was also pretty cool.
Current Limits and Next Steps
The PoC is already usable enough to demonstrate the core idea, but it is obviously not a finished product.
Some requirements were intentionally postponed because they did not fit the common technical path used by most of the first implementation. OIDC authentication is one example. It will be necessary before the application can become a proper production service, but it required additional analysis that would have consumed a significant part of a short PoC. Log download was another. Unlike most of the implemented features, which are mostly based on Kubernetes and Tekton API calls, accessing the logs we want to expose requires an additional integration with the system where they are stored.
Other gaps became more visible during the team demo: the pipeline graph still needs work, both in terms of presentation and in correctly representing some Pipelines as Code cases. For now, known graph limitations can be exposed directly in the interface rather than hidden.
These are exactly the kinds of findings we expected from a PoC. The important result is that the experiment gave us a concrete interface to discuss instead of a list of theoretical requirements. We now have a better idea of which missing features are genuinely important, which ones can remain delegated to Tekton Dashboard, and which parts are worth improving before putting the application in front of users for normal day-to-day work.
For now, the interesting result is simple: a small problem we had been tolerating for quite some time became a functional and fairly polished proof of concept in roughly half a working day. The combination of dedicated time for experimentation, a problem we understood well and AI-assisted development made an idea cheap enough to actually try.
What happens after the PoC may well be material for a second part.
Alessandro Valentini
Author
