TEP-0165: Exploring Tekton Component Release Consolidation

[vdemeester]

This TEP explores options for consolidating Tekton component releases to reduce
maintainer burden, simplify inter-dependency management, and enable atomic
feature delivery across tightly-coupled components.

This TEP does not propose moving all components into a monorepo. Rather, it
seeks to identify which components genuinely benefit from being released
together and which should remain independent. The goal is to start a community
discussion about release coordination strategies and determine the right
approach for different component groupings.

Approach

The TEP proposes a hybrid approach (Option C) with tiered consolidation:

Tier	Components	Strategy
Tier 1	pipeline + CLI	First consolidation candidates
Tier 2	triggers	Evaluate after Tier 1
Tier 3	results, pruner, chains	Evaluate after Tier 2
Tier 4	catlin, mcp-server	Low priority
Keep separate	dashboard, operator, pipelines-as-code	Different tooling/concerns

Key Sections

• Motivation: 5 pain points (release coordination overhead, inter-dependency dance, feature fragmentation, version matrix complexity, contributor context-switching)
• Tiered component analysis: 4 tiers + keep-separate, with rationale per component
• Design details: CI/testing mitigation (change detection, tiered testing), migration strategy with rollback plan, versioning strategy
• Prior art: Kubernetes (monorepo + staging), Knative (polyrepo + shared libs), Istio (consolidated to monorepo), Argo (polyrepo, counter-example)
• 9 open questions for community discussion (scope, starting point, versioning, CI investment, downstream impact, contributor experience, timeline, success criteria, governance/opt-in)

Discussion Sought

This TEP is intentionally exploratory. We're seeking community input on the open questions,
particularly around scope agreement, governance, and downstream impact. Please share your
perspective even if you disagree with the proposed approach — that's exactly the kind of
feedback we need.

/kind tep

[waveywaves]

👍

[waveywaves]

👍

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: waveywaves
To complete the pull request process, please ask for approval from vdemeester after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• teps/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[waveywaves]

My fav thing here is that there would less of a dep dance and CLI can easily keep up with pipelines

[waveywaves]

cc @afrittoli

[afrittoli]

Tekton can be perfectly used without the CLI and even many of our examples do not use tkn. I think it's fine to coordinate releases between pipeline and tkn, and probably the simplest thing to do would be to have automated patch releases for all project and fixed monthly release cadence for all projects.

I believe we can automate things to work around the release dance issue.

But I don't think we have the capacity as a community to start forcing feature parity across components, I think that will make introducing new features much harder, and will start to create user expectations about that.

[chmouel]

The Go workspaces i think is crucial as a potential solution for managing dependencies more efficiently.

Currently, the cli is pulling an unusually large number of dependencies, as evidenced by its binary size:

% du -sh bin/tkn
156M    bin/tkn

While some of these dependencies may not pose significant issues for the CLI itself, there is a legitimate concern about inadvertently introducing unnecessary or bloated dependencies directly into the Tekton Pipeline ecosystem. This could lead to increased complexity, larger container images, or even potential compatibility and security risks.

[chmouel]

But I don't think we have the capacity as a community to start forcing feature parity across components, I think that will make introducing new features much harder, and will start to create user expectations about that.

Feature parity should not be the objective. For example, it should not be a requirement that a contributor implement the same feature in both the backend and the CLI within a single pull request. However, maintaining a shared codebase when updating libraries and dependencies is beneficial. It is also valuable to account for breaking changes that could impact the CLI, rather than allowing those divergences to go unnoticed.

[waveywaves]

It is common for projects to also ship the CLI along with the backend implementation together usually. We don't have to force developers to ship the cli and backend implementations together as you suggested @afrittoli but alluding to @chmouel s point I think maintaining the repositories together is beneficial as UI/UX testing also becomes a lot easier across the board, making sure that the CLI keeps up with the backend whenever there are breaking changes and is something that can be solved instantly instead of realizing only after the version update in the CLI and realizing that there are breaking changes due to the way tekton pipeline works.