[sayan-biswas]

Changes:

• ADR to integrate OpenShift Builds in OpenShift Pipelines

WIP pull request for the changes tektoncd/operator#4130

Type

• New ADR
• Update to existing ADR
• Documentation update

Summary

Checklist

• I have read CONTRIBUTING.md
• This decision belongs in OSP ADRs (not upstream TEPs)
• All ADR sections are filled in
• Consequences include both benefits and drawbacks

[sayan-biswas]

@vdemeester Can you please review this?

[vdemeester]

One nit, but seems good to me !
cc @jkhelil @aThorp96 @waveywaves

[jkhelil]

I have a few concerns here.

This is reasonable as a distribution mechanism (users get Builds "for free" alongside Pipelines), but the mechanism chosen where we are stuffing an unrelated operator's Deployment into this CSV is unusual. OpenShift Builds/Shipwright is a foreign, independently-versioned upstream product with its own operator binary and its own reconciliation loop.

The ADR doesn't currently explain how to resolve these:

• No cross-package upgrade path. OLM's upgrade graph (replaces/skips/skipRange) only operates within one package's channel. openshift-builds-operator (standalone, today) and openshift-pipelines-operator-rh (the CSV this ADR wants to extend) are two entirely different packages. There's no OLM primitive for "Package A's next version is actually delivered inside Package B." A customer's Subscription tracking openshift-builds-operator on channel builds-1.1 will just keep resolving within that package's own graph forever — OLM has no way to redirect them toward Pipelines' CSV automatically.

• CRD ownership conflict. openshift-builds-operator (standalone, e.g. version 1.1–1.6 today, already owns the OpenshiftBuild CRD. OLM enforces single-owner-per-CRD-per-cluster across unrelated CSVs, so any customer with the standalone operator already installed will simply fail to install/upgrade this new CSV until they manually remove it first. There's no migration story for that in the ADR.

• Lockstep release/upgrade coupling. OLM installs/upgrades a CSV atomically. If openshift-builds-operator's deployment is embedded in the same CSV as tekton-operator, both are forced onto the same version number, the same replaces/upgrade graph, and the same release cadence as OpenShift Pipelines. A regression or delayed release in Builds now blocks/couples a Pipelines release, and vice versa. This isn't mentioned in the ADR at all.

• Single failure domain. If the openshift-builds-operator container fails its installStrategy deployment health check, the whole CSV install/upgrade fails — including Pipelines' own deployments — even though a user may not care about Builds.

• RBAC. openshift-builds-operator presumably needs its own ClusterRole/ClusterRoleBinding and SA merged into this CSV's clusterPermissions. Every permission added here is now something the Pipelines operator's SA footprint (or a new SA) carries, which affects the security review surface of Pipelines even for clusters that never enable OpenShiftBuild.

Given these, can the Decision/Consequences section address these points please.

how about the alternative of treaing Shipwright as a Pipelines component instead of embedding a foreign operator:
Rather than embedding openshift-builds-operator as a raw Deployment inside this CSV, why not treat Shipwright/OpenShift Builds like any other Tekton component in this repo — vendor its manifests (Deployment, RBAC, CRDs) and reconcile them through TektonInstallerSet, the same way Chains, Results, Pipelines-as-Code, Pruner, etc. are already handled?

[waveywaves]

how about the alternative of treaing Shipwright as a Pipelines component instead of embedding a foreign operator:
Rather than embedding openshift-builds-operator as a raw Deployment inside this CSV, why not treat Shipwright/OpenShift Builds like any other Tekton component in this repo — vendor its manifests (Deployment, RBAC, CRDs) and reconcile them through TektonInstallerSet, the same way Chains, Results, Pipelines-as-Code, Pruner, etc. are already handled?

I would like to second jawed's point here as well, also the ADR should outline the differences in Pipelines and Builds more clearly. The ADR seems like it's trying to retrofit the Builds operator in the Pipelines oeprator but maybe we need to figure out a way to deploy Shipwright right ? my knowledge on shipwright is minimal or even none right now, but isn't it Tekton a subset of Shipwright ? Maybe we need to build in a way that the components can be configured together properly then. I will have to read up and get back but these are my 2c for now.

[jkhelil]

One more concern: customer experience / consistency.

With this approach, customers don't get to opt in to Builds installing the Pipelines operator installs the Builds operator Deployment too, whether or not they ever use it. And even for those who do want it, the experience is inconsistent with how every other component works today: Chains, Results, PAC, Pruner, Scheduler, etc. are all enabled/configured through one unified TektonConfig CR. Builds would instead need its own separate OpenShiftBuild CR with its own install flow — a second, different pattern customers have to learn.

A cleaner alternative: treat Shipwright/Builds as an OpenShift-specific extension/component of the Pipelines operator (same pattern as TektonAddon — OpenShift-only, opt-in, toggled through TektonConfig), rather than a permanently co-installed foreign operator. That gives customers real opt-in, keeps one consistent install/configure UX, and avoids the CSV/OLM/lifecycle issues raised earlier.

[sayan-biswas]

@jkhelil Added your points in the ADR, also added an alternative proposal through Tekton extension framewprk. PTAL.

[jkhelil]

/approve

[sayan-biswas]

@vdemeester Can we merge this? we are already in the implementable state.