Bug 2032044

Summary:	TektonConfig CRD version label has downstream version number
Product:	Red Hat OpenShift Pipelines	Reporter:	Adam Kaplan <adam.kaplan>
Component:	Operator	Assignee:	Nikhil Thomas <nikthoma>
Status:	VERIFIED ---	QA Contact:	Nobody <nobody>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	1.6	CC:	kbaig, pgarg, ppitonak, sashture, shmingla, vdemeest
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Kaplan 2021-12-13 22:28:21 UTC

Description of problem:

The OpenShift Pipelines operator installs the TektonConfig CustomResourceDefinition with the follwing version number labels:

```
operator.tekton.dev/release=v1.6.0
version=v1.6.0
```

This conflicts with the upstream Tekton operator version scheme. The Shipwright operator uses the CRD's version label to determine if it can deploy Tekton.

Version-Release number of selected component (if applicable): 1.6


How reproducible: Always


Steps to Reproduce:
1. Install the OpenShift Pipelines operator on OpenShift using OLM.
2. Observe the labels on the TektonConfig CRD

Actual results:

The version numbers in the labels correspond to the downstream OpenShift pipelines version.

Expected results:

One of the labels reports the compatible Tekton version of the operator. `operator.tekton.dev/release` might be the better fit.

Additional info:

Comment 1 Nikhil Thomas 2021-12-14 05:49:09 UTC

> One of the labels reports the compatible Tekton version of the operator. `operator.tekton.dev/release` might be the better fit.

I think this could be a good way to handle this. I shall discuss it with my and get back to you

Comment 4 Shubham 2022-10-27 09:55:51 UTC

This is fixed in the latest releases, please let us know if that's not the case!