TEP-0078: Tekton Catalog Support Tiers - User Interface #494

jerop · 2021-08-06T16:01:58Z

The aim of this TEP is surface information about the support tiers for
resources in the Tekton Catalog, Hub and CLI. In addition, this TEP aims
to enable users to filter and search resources from the Tekton Catalog,
Hub and CLI for specific support tiers.

As discussed in TEP-0003: Tekton Catalog Organization,
the support tiers for resources in the Tekton Catalog are community,
verified and official, which are differentiated as such:

	Community	Verified	Official
Automated Testing	❌	✔️	✔️
Images scanned for CVE	❌	❌	✔️
Maintained by Tekton	❌	❌	✔️

Today, all the resources in the Tekton Catalog and Hub should be in the
community support tier, however this information is not surfaced to
users.

We propose adding an optional tekton.dev/tier annotation, which
defaults to community, to resources definitions in the Tekton
Catalog. Then, the support tier will information will be accessible in
the Tekton Hub and CLI as well.

Providing this information in a user-friendly way will set us up
well to support the verified and official resources in the Tekton
Catalog, Hub and CLI.

/kind tep

jerop · 2021-08-06T16:31:56Z

will open a new tep to describe how we'll add verified and official support tiers with automated testing, image scanning and maintenance by tekton -- this tep is focused on the user interaction with the support tiers

chmouel · 2021-08-09T07:00:04Z

Thanks @jerop for starting this.

I am a bit fuzzy if verified is something that we need, if all of them should be just in the community category.

alternatively, maybe community task should be named non-tested ? and verified called community ? But should this be a category, could it just be a "non-tested" tag on community category ?

chmouel · 2021-08-09T07:03:12Z

teps/0078-tekton-catalog-support-tiers.md

+
+### Tekton CLI
+
+After implementation in Tekton Hub, functionality can be extended to the tkn cli. Support tier information should be 


just a imp nit, but it's actually the tkn-hub cli that implement that, tkn-cli simply include the hub cli into its own binary

aah I see, still new to these projects so still figuring it out -- thanks 😀

chmouel · 2021-08-09T07:07:45Z

teps/0078-tekton-catalog-support-tiers.md

+be handled, or user scenarios that will be affected and must be accomodated.
+-->
+
+- Contributor should be able to indicate the support tier of a resource when authoring it.


From what I have seen on the catalog a lot of the contribution are from contributor that contribute task once and not necessary follow up if there is a catalog structure change or an issue/rfe reported unless catalog owners ping them.

If contributor start to indicate that this task is supported, the expectation of the support needs really be on the contributor and not on the catalog owners (since that would not scale).

definitely, the contributor needs to support their resources if they're in the verified tier -- so the catalog owners only maintain the official tier

@vinamra28 and I have been discussing ideas to automate notifying the owners (contributors) about failing tests for their resources (without catalog owners having to ping) -- and right now, we're thinking of creating github issues with a given format and assigning the owners of the specific failing resource (more on this when we get to the proposal bit of #495, trying to keep this TEP focused on the user experience)

Should it be on the author to put this "tier" annotation or should it be part of some automation ?
Ideally, I think it would/could be on an automation to set those. What this means is that either we need to have a different view of the catalog than the source — aka something that is generated from the source, tektoncd/catalog and used by our users. We can think of OCI bundles there, but also another "storage" medium for "resloved"/"tested"/… Tasks coming from the catalog. One "nice" side-effect there, is that we could actually use tagged version (and even latest) on the catalog, but used resolved digest reference for the "generated" catalog.

vdemeester · 2021-08-09T08:05:05Z

/assign

jerop · 2021-08-10T22:41:11Z

thanks for the review @chmouel!

I am a bit fuzzy if verified is something that we need, if all of them should be just in the community category.

my understanding of the community category in TEP-0003 is that it has no testing requirements to ensure a low barrier to contributing resources in the catalog (to encourage more contributions) (cc @bobcatfish)

alternatively, maybe community task should be named non-tested ? and verified called community ? But should this be a category, could it just be a "non-tested" tag on community category ?

are you thinking that there should be two broad categories: community and official resources -- and community resources can be either unverified or verified? please let me know if I got this wrong

if so, i see how verified resources are also community resources because they're maintained by the community as opposed to the official ones that are maintained by owners

@bobcatfish @vdemeester as you authored TEP-0003, would love to hear your thoughts on this

vdemeester · 2021-08-11T08:24:04Z

thanks for the review @chmouel!

I am a bit fuzzy if verified is something that we need, if all of them should be just in the community category.

my understanding of the community category in TEP-0003 is that it has no testing requirements to ensure a low barrier to contributing resources in the catalog (to encourage more contributions) (cc @bobcatfish)

Yes that was the initial take on TEP-0003, to keep the barrier low for contributing resources (at least at the start).

chmouel · 2021-08-11T11:53:14Z

are you thinking that there should be two broad categories: community and official resources -- and community resources can be either unverified or verified? please let me know if I got this wrong

That's correct, I guess the UI tag would indicate if a user wants to install a community task that is verified or not and it doesn't need to be a new category.

bobcatfish · 2021-08-16T16:13:39Z

/assign chmouel
/assign bobcatfish

bobcatfish

Left a bunch of random thougthts, most of which I don't mind if you ignore :)

The one bit of feedback I feel more strongly about: if we're still planning not to have a "verified" tier in the long run, I think maybe we should decide that before/at the same time as this? so we dont implement this with support for all 3 tiers and then have to drop it

(np if that's not the plan anymore tho and im just behind!)

bobcatfish · 2021-09-03T19:50:52Z

teps/0078-tekton-catalog-support-tiers.md

+[documentation style guide]: https://github.com/kubernetes/community/blob/master/contributors/guide/style-guide.md
+-->
+
+The aim of this TEP is surface information about the support tiers - *commmunity*, *verified*, *official* - for 


nit: missing word "to" ("is to surface")

bobcatfish · 2021-09-03T20:01:20Z

teps/0078-tekton-catalog-support-tiers.md

+[experience reports]: https://github.com/golang/go/wiki/ExperienceReports
+-->
+
+As discussed in [TEP-0003: Tekton Catalog Organization](https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md), 


might make sense to link directly to the motivation section in that TEP (https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md#motivation) and/or summarize or copy the reasoning mentioned there?

alternatively, im wondering if you thought about updating TEP-0003 vs making a new TEP?

bobcatfish · 2021-09-03T20:03:08Z

teps/0078-tekton-catalog-support-tiers.md

+and make progress.
+-->
+
+- Establish *verified* and *official* support tiers for resources in the Tekton Catalog - will be done in future work.


am i reading correctly that this TEP is only about how a task author expresses which support tier their task is in?

if so maybe the title could be something like "representing catalog support tiers" or "expressing catalog support level" or something - i thought this was about defining the tiers and requirements themselves up until i got to here

Interesting, I am reading this as "implementing" the verified/official support tiers (aka setting the infra required, …)

bobcatfish · 2021-09-03T20:04:38Z

teps/0078-tekton-catalog-support-tiers.md

+  annotations:
+    tekton.dev/pipelines.minVersion: "0.17.0"
+    tekton.dev/tags: image-build
+    tekton.dev/tier: verified


am i right that there have been other discussions about having just "official" and "community" and dropping verified? im guessing you're trying to tackle one thing at a time but if we're planning to do that maybe it makes sense to mention it here as well?

I think there has been few discussions around that but nothing was decided and we would need to pick those up again.

bobcatfish · 2021-09-03T20:06:20Z

teps/0078-tekton-catalog-support-tiers.md

+Hub UI should have `tier` filter and show resources based on it.
+
+CLI code should be extended:
+- to have `--tier` search parameter to filter resources based on support tiers


i wonder if starting to call this something like "support level" instead of tier might be more meaningful for users?

alternatively, if we are eventually going to have just "official" and "community" the filter could instead be something like --official ? (jumping to conclusions but im guessing thats what users would want vs filtering for community and excluding official?)

If we call it "support level", then we need to define what we mean by "support" and what assumption user should make between each support level. Things like : CVE fixes, time it is support (and will receive fixes …), target on which it is supported on (k8s, gke, openshift, …)

bobcatfish · 2021-09-03T20:08:28Z

teps/0078-tekton-catalog-support-tiers.md

+- Support tier information in the resource yaml in the Catalog should be optional.
+- Definitions and expectations of support tiers should be documented in the Tekton Catalog.
+- Available support tiers should be shown on the Tekton Hub, and users should be able to filter resources based on them.
+- Users should be able to search for resources of specific support tiers using the Tekton CLI.


maybe also:

users of the resource from the catalog should be able to determine the support tier after installing/using/copying the task

bobcatfish · 2021-09-03T20:08:58Z

teps/0078-tekton-catalog-support-tiers.md

+
+However, we need to add more validation to ensure that any combinations of the annotations are compatible. Moreover, for
+every new tier, we will need to add a new annotation instead of extending the acceptable fields.
+


trying to brainstorm other alternatives

we could use folder structure (con: wouldn't be possible to get the support tier info just looking at the task - ive suggested a requirement around this)

we could use separate repositories (same con as previous)

tekton-robot · 2021-12-20T19:48:30Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign bobcatfish
You can assign the PR to them by writing /assign @bobcatfish in a comment when ready.

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

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

As discussed in [TEP-0003: Tekton Catalog Organization](https://github.com/tektoncd/community/blob/main/teps/0003-tekton-catalog-organization.md), the support tiers for resources in the Tekton Catalog are *commmunity*, *verified* and *official*, which are differentiated as such: | | Community | Verified | Official | |:----------------------:|:---------:|:------------------:|:------------------:| | Automated Testing | :x: | :heavy_check_mark: | :heavy_check_mark: | | Images scanned for CVE | :x: | :x: | :heavy_check_mark: | | Maintained by Tekton | :x: | :x: | :heavy_check_mark: | Today, all the resources in the Tekton Catalog and Hub should be in the *community* support tier, however this information is not surfaced to users. The aim of this TEP is surface information about the support tiers for resources in the Tekton Catalog, Hub and CLI. In addition, this TEP aims to enable users to filter and search resources from the Tekton Catalog, Hub and CLI for specific support tiers. We propose adding an optional `tekton.dev/tier` annotation, which defaults to *commmunity*, to resources definitions in the Tekton Catalog. Then, the support tier will information will be accessible in the Tekton Hub and CLI as well. Providing this information in a user-friendly way will set us up well to support the *verified* and *official* resources in the Tekton Catalog, Hub and CLI.

jerop · 2021-12-20T22:19:21Z

closing this in favor of #495 so that we can focus on establishing the support tiers first

we may reopen after we flesh out the details of the support tiers and decide to work on the cli and hub support separately

Catalog - we will explore the proposal in further changes. The aim of this TEP is to establish support tiers for resources in the Tekton Catalog to ensure users get high quality resources that they can rely on while making it easy for contributors to submit resources to the Tekton Catalog. The goals of the TEP are to address the following aspects of the Tekton Catalog: - Ownership and Maintenance - Automated Testing and Dogfooding - Image Scanning for Common Vulnerabilities and Exposures (CVEs) - Verified Remote Resources Related PRs: - tektoncd#494 - tektoncd#170 - tektoncd#495

This change adds the problem statement for Support Tiers in the Tekton Catalog - we will explore the proposal in further changes. The aim of this TEP is to establish support tiers for resources in the Tekton Catalog to ensure users get high quality resources that they can rely on while making it easy for contributors to submit resources to the Tekton Catalog. The goals of the TEP are to address the following aspects of the Tekton Catalog: - Ownership and Maintenance - Automated Testing and Dogfooding - Image Scanning for Common Vulnerabilities and Exposures (CVEs) - Verified Remote Resources Related PRs: - tektoncd#494 - tektoncd#170 - tektoncd#495

This change adds the problem statement for Support Tiers in the Tekton Catalog - we will explore the proposal in further changes. The aim of this TEP is to establish support tiers for resources in the Tekton Catalog to ensure users get high quality resources that they can rely on while making it easy for contributors to submit resources to the Tekton Catalog. The goals of the TEP are to address the following aspects of the Tekton Catalog: - Ownership and Maintenance - Automated Testing and Dogfooding - Image Scanning for Common Vulnerabilities and Exposures (CVEs) - Verified Remote Resources Related PRs: - #494 - #170 - #495

tekton-robot added the kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). label Aug 6, 2021

tekton-robot requested review from chmouel and piyush-garg August 6, 2021 16:02

tekton-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Aug 6, 2021

jerop force-pushed the tekton-catalog-support-tiers branch from 4d254eb to 4370f0a Compare August 6, 2021 16:04

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 6, 2021

jerop force-pushed the tekton-catalog-support-tiers branch from 4370f0a to 07bdbc9 Compare August 6, 2021 16:47

chmouel reviewed Aug 9, 2021

View reviewed changes

tekton-robot assigned vdemeester Aug 9, 2021

jerop mentioned this pull request Aug 9, 2021

TEP-0079: Tekton Catalog Support Tiers [Problem Statement] #495

Merged

tekton-robot assigned bobcatfish and chmouel Aug 16, 2021

tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 24, 2021

bobcatfish reviewed Sep 3, 2021

View reviewed changes

jerop force-pushed the tekton-catalog-support-tiers branch from 07bdbc9 to b18e5c5 Compare December 20, 2021 19:48

tekton-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Dec 20, 2021

jerop force-pushed the tekton-catalog-support-tiers branch from b18e5c5 to 15e88bd Compare December 20, 2021 22:16

jerop changed the title ~~TEP-0078: Tekton Catalog Support Tiers~~ TEP-0078: Tekton Catalog Support Tiers - User Interface Dec 20, 2021

jerop closed this Dec 20, 2021

jerop mentioned this pull request Jan 6, 2022

TEP-0079: Tekton Catalog Support Tiers [Problem Statement] #597

Merged

jerop deleted the tekton-catalog-support-tiers branch January 29, 2022 19:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

TEP-0078: Tekton Catalog Support Tiers - User Interface #494

TEP-0078: Tekton Catalog Support Tiers - User Interface #494

jerop commented Aug 6, 2021 •

edited

Loading

jerop commented Aug 6, 2021

chmouel commented Aug 9, 2021 •

edited

Loading

chmouel Aug 9, 2021 •

edited

Loading

jerop Aug 10, 2021

chmouel Aug 9, 2021

jerop Aug 10, 2021

vdemeester Oct 25, 2021

vdemeester commented Aug 9, 2021

jerop commented Aug 10, 2021

vdemeester commented Aug 11, 2021

chmouel commented Aug 11, 2021

bobcatfish commented Aug 16, 2021

bobcatfish left a comment

bobcatfish Sep 3, 2021

bobcatfish Sep 3, 2021

bobcatfish Sep 3, 2021

vdemeester Oct 25, 2021

bobcatfish Sep 3, 2021

vdemeester Oct 25, 2021

bobcatfish Sep 3, 2021

vdemeester Oct 25, 2021

bobcatfish Sep 3, 2021

bobcatfish Sep 3, 2021

tekton-robot commented Dec 20, 2021

jerop commented Dec 20, 2021


		### Tekton CLI

		After implementation in Tekton Hub, functionality can be extended to the tkn cli. Support tier information should be


		However, we need to add more validation to ensure that any combinations of the annotations are compatible. Moreover, for
		every new tier, we will need to add a new annotation instead of extending the acceptable fields.

TEP-0078: Tekton Catalog Support Tiers - User Interface #494

TEP-0078: Tekton Catalog Support Tiers - User Interface #494

Conversation

jerop commented Aug 6, 2021 • edited Loading

jerop commented Aug 6, 2021

chmouel commented Aug 9, 2021 • edited Loading

chmouel Aug 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vdemeester commented Aug 9, 2021

jerop commented Aug 10, 2021

vdemeester commented Aug 11, 2021

chmouel commented Aug 11, 2021

bobcatfish commented Aug 16, 2021

bobcatfish left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tekton-robot commented Dec 20, 2021

jerop commented Dec 20, 2021

jerop commented Aug 6, 2021 •

edited

Loading

chmouel commented Aug 9, 2021 •

edited

Loading

chmouel Aug 9, 2021 •

edited

Loading