What needs improvement with Tekton?

Regarding areas for improvement in Tekton, I have not encountered significant issues. It works well for our use case. However, incorporating AI could be a potential enhancement in the future.

Tekton should have more accessibility for some rare use cases so that we can have more references when applying some techniques to our pipeline.

It would be better if Tekton could show the YAML file while it is running, similar to GitHub pipelines, to provide more visibility on what's happening. We need information on the duration and specifics of the running pipeline for easier analysis.

RBAC is really needed for Tekton. Also, if you have too many PVCs and don't clean them up, it may stop working due to the limited number of PVCs you can create in a cluster.

Tekton lacks integration capabilities compared to other CI/CD tools like Jenkins and Travis. For instance, Jenkins offers plugins that facilitate easy integration with other software delivery tools. Tekton needs to improve its endpoint communication routes for better integration. Another area for improvement is security management. Jenkins offers RBAC for user access management, which Tekton lacks. Additionally, Tekton currently has no backup mechanism for execution logs, which puts run-related data at risk of loss.

While Tekton is highly effective for Kubernetes-based setups, it might not suit users who require more control over bare-metal environments.

There might be some compatibility issues and the need for customization during deployment, especially when deploying to different environments.

Initially, working with YAML configuration can be challenging using the solution.

The product's documentation is an area of concern, making it an area where improvements are required. Apart from the documentation, there is one more thing that I believe needs to improve in Tekton. In the Tekton pipeline structure, there is an optional feature called finally section, where we can add all the core Tekton Tasks, which have to be executed even in a pipeline failure scenario. But the issue is that we cannot give a sequence for the tasks in the finally section, so all the tasks are running simultaneously. I believe if we had a feature to help users add a sequence for the tasks in the finally section, then it would make our lives easier. The scalability could improve a lot in the future.

Compared to traditional tools like Jenkins, Tekton lacks a lot of features. It's not efficient in managing conflicts between multiple pipelines. If I execute a test and someone else executes a test, we face lots of conflicts and overwriting of each other's work. That's one area for improvement. Also, the reliability of Tekton is sometimes an issue. I think it's more of a Kubernetes-related issue than a Tekton issue. There are more outages than we expect. We have a strict requirement of running tests four to five times a day, and sometimes it's not able to provision the pipeline on time, so we lose test runs.

Some of the tool's cons include its minimalistic dashboard, which lacks detailed information and control compared to other tools like Jenkins or GitLab. Additionally, it's primarily used by Japanese companies. Another drawback is its dependency on the Kubernetes cluster for deployment, which could be a limitation. One feature I would like to see included or enhanced in Tekton is the ability to reuse specific pieces of pipelines as reusable modules. I didn't choose this tool because they already used it when I joined this company. I don't like this tool because it has many limitations. I believe many other tools are better than Tekton. Integration with other solutions involves mainly API calls. Tekton lacks a mature dashboard, making integration more challenging than tools like GitLab or Jenkins. I encountered some challenges, particularly with compatibility between different versions of Tekton and Kubernetes. For example, the Tekton version couldn't be installed on Kubernetes version 1.24 due to compatibility issues. Some versions of Tekton don't support certain Kubernetes features, leading to installation issues. It depends on Kubernetes, and matching Tekton versions with compatible ones is essential. The tool has increased our operational costs due to the need for repetitive tasks and code duplication. Unlike other tools like GitLab or Jenkins, it often requires duplicating resources across clusters or regions. This duplication elevates maintenance costs, as any code changes must be applied in multiple locations.

The deployment could be more accessible.

It tends to occupy a significant amount of disk space on the node, which could potentially pose challenges. This aspect could be enhanced for better efficiency. Additionally, the build time, particularly for larger applications, seems a bit extended, ranging from five to ten minutes in some cases. There's room for improvement to streamline and minimize the build time.

There might be occasional issues with storage or cluster-level logging, which can affect production. But as a component, Tekton performs flawlessly. As an orchestrator, Tekton effectively executes most tasks. However, there are instances where we feel that YAML files, which Tekton reads, could benefit from increased flexibility. You see, in OpenShift, everything revolves around YAML. We have different components specified in YAML files, and when we put them together in an OpenShift pipeline, it generally works fine. However, occasionally we encounter difficulties when editing these YAML files.

There is a need for substantial improvement in connecting with other tools and open-source software. Configuring Tekton requires a deep understanding of Kubernetes, which can be difficult for developers. Furthermore, there is no existing template that gives defaults for developers to build a pipeline, making it challenging for them to use. In conclusion, Tekton is not particularly user-friendly for developers and has room for improvement. I would like Tekton to change its dashboard to be similar to the one GitLab offers.