https://github.com/rootfs/knative-build
A K8s-native Build resource.
https://github.com/rootfs/knative-build
Last synced: 5 months ago
JSON representation
A K8s-native Build resource.
- Host: GitHub
- URL: https://github.com/rootfs/knative-build
- Owner: rootfs
- License: apache-2.0
- Created: 2018-06-08T19:33:05.000Z (almost 8 years ago)
- Default Branch: master
- Last Pushed: 2018-07-16T21:25:11.000Z (almost 8 years ago)
- Last Synced: 2024-12-29T21:23:09.703Z (over 1 year ago)
- Language: Go
- Homepage:
- Size: 6.9 MB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Roadmap: roadmap-2018.md
Awesome Lists containing this project
README
# 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](./CONTRIBUTING.md)
and [DEVELOPMENT.md](./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](
https://kubernetes.io/docs/concepts/api-extension/custom-resources/) 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](./pkg/builder) implementation that delegates Builds to hosted
services (e.g. [Google Container Builder](./pkg/builder/google)), 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](./roadmap-2018.md)
## Terminology and Conventions
* [Builds](./builds.md)
* [Build Templates](./build-templates.md)
* [Builders](./builder-contract.md)
* [Authentication](./cmd/creds-init/README.md)
## Getting Started
You can install the latest release of the Build CRD by running:
```shell
kubectl create -f https://storage.googleapis.com/build-crd/latest/release.yaml
```
### Run your first `Build`
Create your first `build.yaml`:
```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:
```shell
$ kubectl apply -f build.yaml
build "hello-build" created
```
Check that it was created:
```shell
$ kubectl get builds
NAME AGE
hello-build 4s
```
Get more information about the build:
```shell
$ 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!
```shell
$ kubectl get pod hello-build-jx4ql -oyaml
...lots of interesting stuff!
```
Here's a shortcut for getting a build's underlying `podName`:
```shell
$ 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.
```shell
$ kubectl logs $(kubectl get build hello-build -ojsonpath={.status.cluster.podName}) -c build-step-hello
hello build
```
:tada: