You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[GitHub access via SSH](https://help.github.com/articles/connecting-to-github-with-ssh/)
18
-
1.[Create and checkout a repo fork](#checkout-your-fork)
19
-
1. Install [requirements](#requirements)
20
-
1.[Set up a Kubernetes cluster](#create-a-cluster-and-a-repo)
21
-
1. Set up your [shell environment](#environment-setup)
22
-
1.[Configure kubectl to use your cluster](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
23
-
1.[Install Shipwright Build in your cluster](#install-shipwright-build)
18
+
4.[Create and checkout a repo fork](#checkout-your-fork)
19
+
5. Install [requirements](#requirements)
20
+
6.[Set up a Kubernetes cluster](#create-a-cluster-and-a-repo)
21
+
7. Set up your [shell environment](#environment-setup)
22
+
8.[Configure kubectl to use your cluster](https://kubernetes.io/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)
23
+
9.[Install Shipwright Build in your cluster](#install-shipwright-build)
24
24
25
25
### Ramp up
26
26
@@ -58,9 +58,9 @@ The Go tools require that you clone the repository to the
58
58
59
59
To check out this repository:
60
60
61
-
1.Create your own
61
+
1. Create your own
62
62
[fork of this repo](https://help.github.com/articles/fork-a-repo/)
63
-
1. Clone it to your machine:
63
+
2. Clone it to your machine:
64
64
65
65
```shell
66
66
mkdir -p ${GOPATH}/src/github.com/shipwright-io
@@ -78,27 +78,27 @@ _Adding the `upstream` remote sets you up nicely for regularly
78
78
79
79
You must install these tools:
80
80
81
-
1.[`go`](https://golang.org/doc/install): The language Shipwright Build is
81
+
1.[`go`](https://golang.org/doc/install): The language Shipwright Build is
82
82
built in
83
-
1.[`git`](https://help.github.com/articles/set-up-git/): For source control
84
-
1 [`ko`](https://github.com/ko-build/ko): To build and deploy changes.
85
-
1.[`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/): For
83
+
2.[`git`](https://help.github.com/articles/set-up-git/): For source control
84
+
3.[`ko`](https://github.com/ko-build/ko): To build and deploy changes.
85
+
4.[`kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/): For
86
86
interacting with your kube cluster
87
87
88
88
### Create a cluster and a repo
89
89
90
90
1. Follow the instructions in the Kubernetes doc to [Set up a kubernetes cluster](https://kubernetes.io/docs/setup/)
91
-
1. Set up a container image repository for pushing images. Any container image registry that is accessible to your cluster can be used for your repository. This can be a public registry like [Docker Hub](https://docs.docker.com/docker-hub/), [quay.io](https://quay.io), or a container registry runs by your cloud provider
91
+
2. Set up a container image repository for pushing images. Any container image registry that is accessible to your cluster can be used for your repository. This can be a public registry like [Docker Hub](https://docs.docker.com/docker-hub/), [quay.io](https://quay.io), or a container registry runs by your cloud provider
92
92
93
93
**Note**: We support Kubernetes version 1.27 to 1.29. 1 cluster worker node for basic usage, 2+ cluster worker nodes for HA
94
94
95
95
## Environment Setup
96
96
97
97
To run your controller, you'll need to set these environment variables (we recommend adding them to your `.bashrc`):
98
98
99
-
1.`GOPATH`: If you don't have one, simply pick a directory and add `export
99
+
1.`GOPATH`: If you don't have one, simply pick a directory and add `export
100
100
GOPATH=...`
101
-
1.`$GOPATH/bin` on `PATH`: This is so that tooling installed via `go get` will
101
+
2.`$GOPATH/bin` on `PATH`: This is so that tooling installed via `go get` will
102
102
work properly.
103
103
104
104
`.bashrc` example:
@@ -126,11 +126,11 @@ The following set of steps highlight how to deploy a Build controller pod into a
126
126
./hack/install-tekton.sh
127
127
```
128
128
129
-
1. Set your `KO_DOCKER_REPO` environment variable. This will be the container
129
+
2. Set your `KO_DOCKER_REPO` environment variable. This will be the container
130
130
image registry you push to, or `kind.local`if you're using
131
131
[KinD](https://kind.sigs.k8s.io).
132
132
133
-
1. Build and deploy the controller from source, from within the root of the repo:
133
+
3. Build and deploy the controller from source, from within the root of the repo:
Copy file name to clipboardExpand all lines: docs/build.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -126,7 +126,7 @@ A `Build` resource can specify a source type, such as a Git repository or an OCI
126
126
-`source.type` - Specify the type of the data-source. Currently, the supported types are "Git", "OCIArtifact", and "Local".
127
127
-`source.git.url` - Specify the source location using a Git repository.
128
128
-`source.git.cloneSecret` - For private repositories or registries, the name references a secret in the namespace that contains the SSH private key or Docker access credentials, respectively.
129
-
-`source.git.revision` - A specific revision to select from the source repository, this can be a commit, tag or branch name. If not defined, it will fallback to the Git repository default branch.
129
+
-`source.git.revision` - A specific revision to select from the source repository, this can be a commit, tag or branch name. If not defined, it will fall back to the Git repository default branch.
130
130
-`source.contextDir` - For repositories where the source code is not located at the root folder, you can specify this path here.
131
131
132
132
By default, the Build controller does not validate that the Git repository exists. If the validation is desired, users can explicitly define the `build.shipwright.io/verify.repository` annotation with `true`. For example:
@@ -283,7 +283,7 @@ spec:
283
283
284
284
### Defining ParamValues
285
285
286
-
A `Build` resource can specify _paramValues_ for parameters that are defined in the referenced `BuildStrategy`. You specify these parameter values to control how the steps of the build strategy behave. You can overwrite values in the `BuildRun` resource. See the related [documentation](./buildrun.md#defining-params) for more information.
286
+
A `Build` resource can specify _paramValues_ for parameters that are defined in the referenced `BuildStrategy`. You specify these parameter values to control how the steps of the build strategy behave. You can overwrite values in the `BuildRun` resource. See the related [documentation](buildrun.md#defining-paramvalues) for more information.
287
287
288
288
The build strategy author can define a parameter as either a simple string or an array. Depending on that, you must specify the value accordingly. The build strategy parameter can be specified with a default value. You must specify a value in the `Build` or `BuildRun` for parameters without a default.
Copy file name to clipboardExpand all lines: docs/buildrun.md
+2-2
Original file line number
Diff line number
Diff line change
@@ -392,7 +392,7 @@ The following table illustrates the different states a BuildRun can have under i
392
392
| False | BuildRunAmbiguousBuild | Yes | The defined `BuildRun` uses both `spec.build.name` and `spec.build.spec`. Only one of them is allowed at the same time. |
393
393
| False | BuildRunBuildFieldOverrideForbidden | Yes | The defined `BuildRun` uses an override (e.g. `timeout`, `paramValues`, `output`, or `env`) in combination with `spec.build.spec`, which is not allowed. Use the `spec.build.spec` to directly specify the respective value. |
394
394
| False | PodEvicted | Yes | The BuildRun Pod was evicted from the node it was running on. See [API-initiated Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/api-eviction/) and [Node-pressure Eviction](https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/) for more information. |
395
-
| False | StepOutOfMemory | Yes | The BuildRun Pod failed because a step went out of memory. |
395
+
| False | StepOutOfMemory | Yes | The BuildRun Pod failed because a step went out of memory. |
396
396
397
397
**Note**: We heavily rely on the Tekton TaskRun [Conditions](https://github.com/tektoncd/pipeline/blob/main/docs/taskruns.md#monitoring-execution-status) for populating the BuildRun ones, with some exceptions.
398
398
@@ -524,4 +524,4 @@ For every BuildRun controller reconciliation, the `buildSpec` in the status of t
524
524
525
525
The `BuildRun` resource abstracts the image construction by delegating this work to the Tekton Pipeline [TaskRun](https://github.com/tektoncd/pipeline/blob/main/docs/taskruns.md). Compared to a Tekton Pipeline [Task](https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md), a `TaskRun` runs all `steps` until completion of the `Task` or until a failure occurs in the `Task`.
526
526
527
-
During the Reconcile, the `BuildRun` controller will generate a new `TaskRun`. The controller will embed in the `TaskRun` `Task` definition the requires `steps` to execute during the execution. These `steps` are defined in the strategy defined in the `Build` resource, either a `ClusterBuildStrategy` or a `BuildStrategy`.
527
+
During the Reconcile, the `BuildRun` controller will generate a new `TaskRun`. The controller will embed in the `TaskRun` `Task` definition the required `steps` to execute during the execution. These `steps` are defined in the strategy defined in the `Build` resource, either a `ClusterBuildStrategy` or a `BuildStrategy`.
0 commit comments