The destination uses the provided template parameter  ${IMAGE} . This template can then be used by a Build, which specifies the name of the template instead of a list of steps as seen in Example 25-5. As you can see, you have to specify only the name of the application container image to create, and you can easily reuse this multistep build to create different applications. Source specification for where to pick up the source code Reference to template we defined in Example 25-4 Image specification filled into the template as parameter You can find many predefined templates in the Knative build-templates repository. This example ends our quick tour through Knative build. As mentioned, this project is still very young and the details are likely to change, but the main mechanics described here should stay the same. You have seen two ways to build container images within a cluster. The OpenShift build system demonstrates nicely one of the main benefits of building and running an application in the same cluster. With OpenShift’s ImageStream triggers, you can not only connect multiple builds, but also redeploy your application if a build updates your application’s container image. This is especially useful for lower environments where a build step is usually followed by a deploy step. Better integration between build and deployment is a step forward to the holy grail of CD. OpenShift builds with 234  |  Chapter 25: Image Builder Discussion Example 25-5. Knative build using a build template apiVersion : build.knative.dev/v1alpha1 kind : Build metadata : name : random-generator-build-chained spec : source : git : url : https://github.com/k8spatterns/random-generator.git revision : master template : name : maven-kaniko arguments : -  name : IMAGE value : registry:80/k8spatterns/random-generator