On Custom Tasks usage and "authoring"

[vdemeester]

This might be a "too generic" topic but I want to start a discussion on Custom Tasks, if and how they are used, and gather feedback about it.

Custom Task (or CustomRun) are a type of Task that can be referred in Pipeline or TaskRun to do not rely on the Task implement but instead of a “custom” behavior. That behavior is entirely up to the Custom Task maintainer to decide. It can be doing somethink in memory, consuming an external service, creating a set of Kubernetes object, … The sky is the limit really.

Custom Task have been introduced as an extension point for Pipeline / Task. Technically, they rely on an addtionnal object (CRD) defined in the Cluster, as well as, at least, a controller to reconcile it (aka updating the status, …).

There is no supported custom tasks shipped today as part of tektoncd/pipeline or the tekton organization. There is however a small number of them in the tektoncd/experimental repository, but not really maintained.

Questions for users…

• Are you using Custom Task in your cluster(s) ?
  • If yes, which ones ?
• If not, what may be the reason of not using them ?
• How are you willing to depend on Custom Task ?

… For tektoncd/pipeline maintainers

• How do we measure success of Custom Task ?
• Why are we not creating more Custom Task ourselves to explore and provide “custom”/”optional” behavior ?

Summary

I will try to keep this part updated with a summary of the discussion (if any) in order to produce some sort of TL;DR for readers that may not want to read the full discussion

[SaschaSchwarze0]

Shipwright Triggers is providing a custom task implemention to run an image build as part of a pipeline. Works beautifully though not yet complete. The challenging capability that we still need to implement is to pass a workspace from a pipeline to a BuildRun. I don't remember other hurdles when we implemented it (okay, the rename from Run to CustomRun was not fun, given we have not released the project, we were lucky and could just drop the Run support).

[lcarva]

Having to write a CRD and a controller in order to use a feature is a really high entry barrier. It's a powerful feature and there are certainly benefits in doing so, but IMO this is reserved to very specific use cases. This is further complicated if I'm a user of a cluster maintained by another team in my organization, e.g. IT.

If these were provided, as production grade, by either Tekton itself, or another reputable community, then those concerns are reduced. What lingers is a sense that I now need a non-standard Tekton installation. But this is arguably easier to overcome.