Use the Build
resource object to create and run on-cluster processes to
completion.
To create a build in Knative, you must define a configuration file, in which specifies one or more container images that you have implemented to perform and complete a task.
A build runs until all steps
have completed or until a failure occurs.
To define a configuration file for a Build
resource, you can specify the
following fields:
- Required:
apiVersion
- Specifies the API version, for examplebuild.knative.dev/v1alpha1
.kind
- Specify theBuild
resource object.metadata
- Specifies data to uniquely identify theBuild
resource object, for example aname
.spec
- Specifies the configuration information for yourBuild
resource object. Build steps must be defined through either of the following fields:
- Optional:
source
- Specifies a container image that provides information to your build.serviceAccountName
- Specifies aServiceAccount
resource object that enables your build to run with the defined authentication information.volumes
- Specifies one or more volumes that you want to make available to your build.timeout
- Specifies timeout after which the build will fail.
The following example is a non-working sample where most of the possible configuration fields are used:
apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
name: example-build-name
spec:
serviceAccountName: build-auth-example
source:
git:
url: https://github.com/example/build-example.git
revision: master
steps:
- name: ubuntu-example
image: ubuntu
args: ["ubuntu-build-example", "SECRETS-example.md"]
steps:
- image: gcr.io/example-builders/build-example
args: ['echo', 'hello-example', 'build']
steps:
- name: dockerfile-pushexample
image: gcr.io/example-builders/push-example
args: ["push", "${IMAGE}"]
volumeMounts:
- name: docker-socket-example
mountPath: /var/run/docker.sock
volumes:
- name: example-volume
emptyDir: {}
The steps
field is required if the template
field is not defined. You
define one or more steps
fields to define the body of a build.
Each steps
in a build must specify a Builder
, or type of container image that
adheres to the Knative builder contract. For each of
the steps
fields, or container images that you define:
- The
Builder
-type container images are run and evaluated in order, starting from the top of the configuration file. - Each container image runs until completion or until the first failure is detected.
For details about how to ensure that you implement each step to align with the
"builder contract", see the Builder
reference topic.
The template
field is a required if no steps
are defined. Specifies a
BuildTemplate
resource object, in which includes
repeatable or sharable build steps
.
For examples and more information about build templates, see the
BuildTemplate
reference topic.
Optional. Specifies a container image. Use the source
field to provide your
build with data or context that is needed by your build. The data is placed into
the /workspace
directory within a mounted
volume and is available
to all steps
of your build.
The currently supported types of sources include:
-
git
- A Git based repository. Specify theurl
field to define the location of the container image. Specify arevision
field to define a branch name, tag name, commit SHA, or any ref. Learn more about revisions in Git. -
gcs
- An archive that is located in Google Cloud Storage. -
custom
- An arbitrary container image.
Optional. Specifies the name
of a ServiceAccount
resource object. Use the
serviceAccountName
field to run your build with the privileges of the
specified service account. If no serviceAccountName
field is specified,
your build runs using the
default
service account
that is in the
namespace
of the Build
resource object.
For examples and more information about specifying service accounts,
see the ServiceAccount
reference topic.
Optional. Specifies one or more volumes that you want to make available to your build, including all the build steps. Add volumes to complement the volumes that are implicitly created during a build step.
For example, use volumes to accomplish one of the following common tasks:
-
Create an
emptyDir
volume to act as a cache for use across multiple build steps. Consider using a persistent volume for inter-build caching. -
Mount a host's Docker socket to use a
Dockerfile
for container image builds.
Optional. Specifies timeout for the build. Includes time required for allocating resources and execution of build.
- Defaults to 10 minutes.
- Refer to Go's ParseDuration documentation for expected format.
Use these code snippets to help you understand how to define your Knative builds.
Tip: See the collection of simple test builds for additional code samples, including working copies of the following snippets:
git
assource
gcs
assource
custom
assource
- Mounting extra volumes
- Pushing an image
- Authenticating with
ServiceAccount
- Timeout
Specifying git
as your source
:
spec:
source:
git:
url: https://github.com/knative/build.git
revision: master
steps:
- image: ubuntu
args: ["cat", "README.md"]
Specifying gcs
as your source
:
spec:
source:
gcs:
type: Archive
location: gs://build-crd-tests/rules_docker-master.zip
steps:
- name: list-files
image: ubuntu:latest
args: ["ls"]
Specifying custom
as your source
:
spec:
source:
custom:
image: gcr.io/cloud-builders/gsutil
args: ["rsync", "gs://some-bucket", "."]
steps:
- image: ubuntu
args: ["cat", "README.md"]
Mounting multiple volumes:
spec:
steps:
- image: ubuntu
entrypoint: ["bash"]
args: ["-c", "curl https://foo.com > /var/my-volume"]
volumeMounts:
- name: my-volume
mountPath: /var/my-volume
- image: ubuntu
args: ["cat", "/etc/my-volume"]
volumeMounts:
- name: my-volume
mountPath: /etc/my-volume
volumes:
- name: my-volume
emptyDir: {}
Defining a steps
to push a container image to a repository.
spec:
parameters:
- name: IMAGE
description: The name of the image to push
- name: DOCKERFILE
description: Path to the Dockerfile to build.
default: /workspace/Dockerfile
steps:
- name: build-and-push
image: gcr.io/kaniko-project/executor
args:
- --dockerfile=${DOCKERFILE}
- --destination=${IMAGE}
Specifying a ServiceAccount
to access a private git
repository:
apiVersion: build.knative.dev/v1alpha1
kind: Build
metadata:
name: test-build-with-serviceaccount-git-ssh
labels:
expect: succeeded
spec:
serviceAccountName: test-build-robot-git-ssh
source:
git:
url: [email protected]:knative/build.git
revision: master
steps:
- name: config
image: ubuntu
command: ["/bin/bash"]
args: ["-c", "cat README.md"]
Where serviceAccountName: test-build-robot-git-ssh
references the following
ServiceAccount
:
apiVersion: v1
kind: ServiceAccount
metadata:
name: test-build-robot-git-ssh
secrets:
- name: test-git-ssh
And name: test-git-ssh
, references the following Secret
:
apiVersion: v1
kind: Secret
metadata:
name: test-git-ssh
annotations:
build.knative.dev/git-0: github.com
type: kubernetes.io/ssh-auth
data:
# Generated by:
# cat id_rsa | base64 -w 1000000
ssh-privatekey: LS0tLS1CRUdJTiBSU0EgUFJJVk.....[example]
# Generated by:
# ssh-keyscan github.com | base64 -w 100000
known_hosts: Z2l0aHViLmNvbSBzc2g.....[example]
Note: For a working copy of this ServiceAccount
example, see the
build/test/git-ssh
code sample.
Specifying timeout
for your build
:
spec:
timeout: 20m
source:
git:
url: https://github.com/knative/build.git
revision: master
steps:
- image: ubuntu
args: ["cat", "README.md"]
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License.