

Knative Build Pipeline is the successor to Knative Build. It aims to support complete CI/CD flows and is under alpha development, but you can already use it to build container images in your Kubernetes cluster.
Where Knative Build used BuildTemplates, pipeline uses Tasks. The migration is quite straightforward. Let’s say we have a two-step function (as-a-service) build, the first generates a Dockerfile that the second builds using Kaniko. The old template would have looked like this:
To run that you would have a Build – possibly generated through a Configuration – that specified the source, i.e. git url, along with the parameter values as template arguments.
Tasks use a similar structure but different conventions for parameters, which we’ll get to shortly. First more juicy yaml:
Where steps are identical to those in the BuildTemplate… almost. For now copy your steps along to the new yaml and let’s see below what to update.
Build Pipeline represents your source repository and target image as Resources. While migrating from Build to TaskRun you’ll want to extract those. Note how the Task definition takes some parameters TaskRun and some for resources:
The Task definition is complete, so go ahead and apply it. Now in order to run the build you must provide PipelineResource “git” and “buildImage” together with a TaskRun. See for example our azure example for the yaml. We keep the resources in a separate yaml because we might want to some day reuse them in a PipelineRun, where they have the role of carrying state between tasks.
Let’s run our nodejs example to see what it looks like. After the “kubectl apply” we might see a pod, but if not maybe:
Oops, forgot to apply the resources yaml. Apply that and a pod starts:
The build steps are init containers. We can see the output of each step using the container name:
Build completed and pushed to our registry. That’s it. Note that things are under heavy development. These yamls might not be valid as development progresses. Stay tuned for more information.