Chapter 1. Overview of Builds

The Build resource defines the source code of your application and the location where your application images will be pushed. The following example shows a simple build that consists of a Git source, a build strategy, and an output image:

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://github.com/username/taxi
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
    image: registry.mycompany.com/my-org/taxi-app:latest

You can also extend a Build resource to push your images to a private registry or use a Dockerfile.

The BuildStrategy and ClusterBuildStrategy resources define a series of steps to assemble an application. You can use the BuildStrategy resources within a namespace and the ClusterBuildStrategy resources within a cluster.

The specification of a BuildStrategy or ClusterBuildStrategy resource consists of a steps object. The following example shows the specification of the buildah cluster build strategy:

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: buildah
spec:
  steps:
    - name: build-and-push
      image: quay.io/containers/buildah:v1.31.0
      workingDir: $(params.shp-source-root)
      command:
        - /bin/bash
       # ...
# ...

A BuildRun resource invokes a build on your cluster, similar to any cluster job or Tekton task run. The BuildRun resource represents a workload on your cluster, which results in a running pod. A BuildRun is the running instance of a build. It instantiates a build for execution with specific parameters on a cluster.

A BuildRun resource helps you to define the following elements:

Each BuildRun resource is available within a namespace.

The build controller monitors any updates in the Build resource and performs the following tasks:

The build run controller monitors any updates in the Build or TaskRun resource and performs the following tasks: