Listing Custom Task

[vdemeester]

As Custom Task will go beta (meaning relatively stable and enabled by default), it would be interesting to have a way to register, index, list and read about existing Custom Task. Today most of the Custom Task are written and live in tektoncd/experimental but that's probably going to change as anybody will be able to provide Custom Task.

A few existing Custom Task that lives outside of the tektoncd org today:

• automatiko-approval-task
• tekton-tasgroup-task
• tekton-ocipipeline-task

Ideally, it should be possible to list them from the hub, but it comes with the question on how / where do we want to "register" known / public Custom Task out there.

/cc @tektoncd/hub-maintainers @tektoncd/core-maintainers @tektoncd/experimental-maintainers

[lbernick]

relevant to #523

[jerop]

had a discussion with @vinamra28 about this - we could add a customtasks.yaml to list Custom Tasks surfaced in the Hub, in the same way config.yaml is used for Catalogs. Each entry will provide a Custom Task in the Hub, for example:

custom-tasks:
  
  - name: approval
    org: automatiko-io
    type: community
    provider: github
    url: https://github.com/automatiko-io/automatiko-approval-task
    revision: main
    categories: 
      - Deployment
      - Integration & Delivery
  
  - name: task-group
    org: openshift-pipelines
    type: community
    provider: github
    url: github.com/openshift-pipelines/tekton-task-group
    revision: main
    categories:
      - Openshift
      
  - name: cel
    org: tektoncd
    type: official
    provider: github
    url: github.com/tektoncd/cel
    revision: main

we'd also require that the listed Custom Task has a README.md documenting its functionality, including installation instructions, which will be surfaced in the Hub

what do you think @vdemeester @lbernick?

[vinamra28]

Adding to what @jerop said, each custom task should have metadata, which probably we can keep in an external file (eg metadata.yaml) and should be having following contents:

description:
releaseYaml:
version:
tags:
categories:
platform:
contributor: tekton/openshift/etc

(This is just thinking at high level)

[jerop]

another idea is to provide the custom tasks controllers through the operator - then the hub contains the instances of the custom tasks