Design alternative Task Implementations inside a pipeline

[dlorenc]

Right now A Pipeline is a graph of Tasks, where Tasks are coupled to a Build, which run as a Pod. We'll eventually need to support alternative implementations for the Build/Task execution for cases like:

• Builds that cannot be containerized for some reason
• Builds that must run on a specific piece of hardware (Mac/iOS)
• Manual approval steps where a busy-looping container would be wasteful

< other use cases here >

[dlorenc]

cc @bobcatfish @abayer

[tanner-bruce]

Builds that must run on a specific piece of hardware (Mac/iOS)

knative/build#236 could be one possible solution

[dlorenc]

Ref #781

[mumoshu]

I have following use-cases to add :)

• Runs Helmfile against the specified source to deploy a module of K8s apps
• Runs any command in an existing pod i.e. kubectl exec, without bringing up a pod dedicated for running kubectl exec itself.
• Sends a HTTP request to the specified endpoint, without creating a pod dedicated for running e.g. curl, and without maintaining the code in-tree.

For those, I'd be happy if Tekton provides us API to build and integrate a "custom task controller" in golang, where we have freedom to implement any logics to run the task in the controller.

I think we have three ways to achieve it in general:

1. Add something like a CRD for Tekton Tasks
2. Add a dedicated, Tekton-defined CRD for custom tasks
3. Enhance the existing Task type to allow specifying the controller handles tasks, by controller
   name.

Add something like a CRD for Tekton Tasks

This can possibly be composed of:

• Add tekton controllers an ability to handle any API resources in as unstructured. The user may name the CRD freely, like MyCustomTask
• Enhance PipelineRun and TaskRun types to accept settings to create any K8s resources instead of tasks

One possible question here is - how Tekton fetches "logs" for the specific unstructured K8s resource?

For that, I believe we need at least a common interface between Tekton and the controller reconciling the K8s resources, maybe something like external_agent_logs in deck.

Add a dedicated, Tekton-defined CRD for custom tasks

Assuming we can use/enhance the existing Task type to cover use-cases involving pods, we'd only need a subset of Task removing pod/container-centric parts.

So it can basically be the same as tekton's Task except that steps can be unstructured(=defined by out-of-tree controllers) from the perspective of tekton's builtin controllers.

The same question about the common interface for fetching logs applies to this as well.

Enhance the existing Task type to allow specifying the controller handles tasks

This would add controllerName: mytaskcontroller to the Task API type, so that Tekton's builtin task controller is considered the default controller, which is used only when a task misses controllerName at all.

In case the custom task controller doesn't support steps, it can skip reading it. The controller would read at least inputs to parameterize the custom task though.

Tekton may provide a framework similar to controller-runtime to help devs building out-of-tree Tekton task controller. It should require at least controllerName as the parameter that is used to filter which tasks to reconcile.

[bobcatfish]

@imjasonh has been working on a design for custom tasks in tekton pipelines

[bobcatfish]

/assign @imjasonh