Build CRD

This repository implements Build and BuildTemplate custom resources for Kubernetes, and a controller for making them work.

If you are interested in contributing, see CONTRIBUTING.md and DEVELOPMENT.md.

Objective

Kubernetes is emerging as the predominant (if not de facto) container orchestration layer. It is also quickly becoming the foundational layer on top of which the ecosystem is building higher-level compute abstractions (PaaS, FaaS). In order to increase developer velocity, these higher-level compute abstractions typically operate on source, not just containers, which must be built.

This repository provides an implementation of the Build CRD that runs Builds on-cluster (by default), because that is the lowest common denominator that we expect users to have available. It is also possible to write a pkg/builder implementation that delegates Builds to hosted services (e.g. Google Container Builder), but these are typically more restrictive.

This project as it exists today is not a complete standalone product that could be used for CI/CD, but it provides a building block to facilitate the expression of Builds as part of larger systems. It might provide a building block for CI/CD in the future

Terminology and Conventions

• Builds
• Build Templates
• Builders
• Authentication

Getting Started

You can install the latest release of the Build CRD by running:

kubectl create -f https://storage.googleapis.com/build-crd/latest/release.yaml

Run your first Build

Create your first build.yaml:

apiVersion: build.dev/v1alpha1
kind: Build
metadata:
  name: hello-build
spec:
  steps:
  - name: hello
    image: busybox
    args: ['echo', 'hello', 'build']

Run it on your Kubernetes cluster:

$ kubectl apply -f build.yaml
build "hello-build" created

Check that it was created:

$ kubectl get builds
NAME          AGE
hello-build   4s

Get more information about the build:

$ kubectl get build hello-build -oyaml
apiVersion: build.dev/v1alpha1
kind: Build
...
status:
  builder: Cluster
  cluster:
    namespace: default
    podName: hello-build-jx4ql
  conditions:
  - state: Complete
    status: "True"
  stepStates:
  - terminated:
      reason: Completed
  - terminated:
      reason: Completed

This indicates that the build finished successfully, and that it ran on a pod named hello-build-jx4ql -- your build will run on a pod with a different name. Let's dive into that pod!

$ kubectl get pod hello-build-jx4ql -oyaml
...lots of interesting stuff!

Here's a shortcut for getting a build's underlying podName:

$ kubectl get build hello-build -ojsonpath={.status.cluster.podName}

The build's underlying pod also contains the build's logs, in an init container named after the build step's name. In the case of this example, the build step's name was hello, so the pod will have an init container named build-step-hello which ran the step.

$ kubectl logs $(kubectl get build hello-build -ojsonpath={.status.cluster.podName}) -c build-step-hello
hello build

🎉