diff --git a/content/docs/blog/posts/2025-12-01-release-v0.18.md b/content/docs/blog/posts/2025-12-01-release-v0.18.md new file mode 100644 index 00000000..4a282ce2 --- /dev/null +++ b/content/docs/blog/posts/2025-12-01-release-v0.18.md @@ -0,0 +1,102 @@ +--- +title: "Shipwright v0.18 Is Here!" +description: "Shipwright v0.18 release announcement with new features, fixes, and deprecations." +icon: "article" +date: "2025-12-04T16:00:00-04:00" +lastmod: "2025-12-04T16:00:00-04:00" +draft: false +author: "Sascha Schwarze ([@SaschaSchwarze0](https://github.com/SaschaSchwarze0))" +--- + +We are excited to announce the release of Shipwright v0.18.0! This release brings a small set of +new features. + +## Build Updates + +In this release, we have made changes under the covers to run containers as much as possible with read-only root file system. Note that those changes are only active as long as you do not overwrite the step templates for out-of-the box containers in the [configuration](/docs/build/configuration/). If you had made customizations there, make sure to merge your changes with our extensions. + +Beside that, we have updated Build to utilize the Tekton v1.6 APIs. The minimum supported Kubernetes version is now v1.32.0. The minimum supported Tekton version is now v0.68.0. + +Check out the full release notes on [GitHub of the v0.18.0 release](https://github.com/shipwright-io/build/releases/tag/v0.18.0) for further details. Note that there is also already a [v0.18.1 release](https://github.com/shipwright-io/build/releases/tag/v0.18.1) that is a rebuild with the new Go version released recently that fixed vulnerabilities + +## CLI Maintenance Update + +The CLI has no new features but updated dependencies. + +See the CLI release notes on [GitHub](https://github.com/shipwright-io/cli/releases/tag/v0.18.0) + +## Operator Update + +The operator was upgraded to deploy Shipwright Build v0.18.0 components. + +In our definition, we have removed the dependency on the cert-manager and Tekton Pipelines. The reason we looked at this was that cert-manager deprecated their operator and does not provide updates anymore. For cert-manager, you now have to use another installation method. See [their installation instructions for your options](https://cert-manager.io/docs/installation/). + +To stay consistent, we also removed our other dependency on Tekton Pipelines. You may still deploy Tekton Pipelines using the operator, but you can now also chose a different installation method. + +See the operator release notes on [GitHub](https://github.com/shipwright-io/operator/releases/tag/v0.18.0) for details. + +## Installing Shipwright + +### Build + +1. Install Tekton v1.6.0: + + ```bash + kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/previous/v1.6.0/release.yaml + ``` + +2. Install v0.18.0 using the release YAML manifest: + + ```bash + kubectl apply --filename https://github.com/shipwright-io/build/releases/download/v0.18.0/release.yaml --server-side + + curl --silent --location https://raw.githubusercontent.com/shipwright-io/build/v0.18.0/hack/setup-webhook-cert.sh | bash + ``` + +3. (Optionally) Install the sample build strategies using the YAML manifest: + + ```bash + kubectl apply --filename https://github.com/shipwright-io/build/releases/download/v0.18.0/sample-strategies.yaml --server-side + ``` + +### CLI + +#### Windows + +```bash +curl --silent --fail --location https://github.com/shipwright-io/cli/releases/download/v0.18.0/shp_0.18.0_windows_x86_64.tar.gz | tar xzf - shp.exe +shp version +shp help +``` + +#### Mac + +```bash +curl --silent --fail --location https://github.com/shipwright-io/cli/releases/download/v0.18.0/shp_0.18.0_macOS_$(uname -m).tar.gz | tar -xzf - -C /usr/local/bin shp +shp version +shp help +``` + +#### Linux + +```bash +curl --silent --fail --location "https://github.com/shipwright-io/cli/releases/download/v0.18.0/shp_0.18.0_linux_$(uname -m | sed 's/aarch64/arm64/').tar.gz" | sudo tar -xzf - -C /usr/bin shp +shp version +shp help +``` + +### Operator + +To deploy and manage Shipwright Builds in your cluster, first ensure the operator v0.18.0 is installed and running on your cluster. You can follow the instructions on [OperatorHub](https://operatorhub.io/operator/shipwright-operator). + +Next, create the following: + +```yaml +--- +apiVersion: operator.shipwright.io/v1alpha1 +kind: ShipwrightBuild +metadata: + name: shipwright-operator +spec: + targetNamespace: shipwright-build +``` diff --git a/content/docs/build/build.md b/content/docs/build/build.md index 729e148c..fb685914 100644 --- a/content/docs/build/build.md +++ b/content/docs/build/build.md @@ -91,7 +91,7 @@ The `Build` definition supports the following fields: - [`kind`](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#required-fields) - Specifies the Kind type, for example `Build`. - [`metadata`](https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#required-fields) - Metadata that identify the custom resource instance, especially the name of the `Build`, and in which [namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) you place it. **Note**: You should use your own namespace, and not put your builds into the shipwright-build namespace where Shipwright's system components run. - `spec.source` - Refers to the location of the source code, for example a Git repository or OCI artifact image. - - `spec.strategy` - Refers to the `BuildStrategy` to be used, see the [examples](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy) + - `spec.strategy` - Refers to the `BuildStrategy` to be used, see the [examples](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy) - `spec.output`- Refers to the location where the generated image would be pushed. - `spec.output.pushSecret`- Reference an existing secret to get access to the container registry. @@ -120,10 +120,11 @@ The `Build` definition supports the following fields: A `Build` resource can specify a source type, such as a Git repository or an OCI artifact, together with other parameters like: -- `source.type` - Specify the type of the data-source. Currently, the supported types are "Git", "OCIArtifact", and "Local". +- `source.type` - Specify the type of the data-source. Currently, the supported types are "Git", "OCI", and "Local". - `source.git.url` - Specify the source location using a Git repository. - `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. - `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. +- `source.git.depth` - The depth of the git clone. If not specified the default value is 1 which means that no history is cloned at all. This is the fastest way to clone a Git repository and in most cases enough as long as you don't have anything in your build logic relying on it. Any value greater than 1 will create a clone with the specified depth. For a full git history clone, depth must be set to 0. **Note**: If you specify a commit sha as revision, then the full history is always cloned before this commit is checked out. - `source.contextDir` - For repositories where the source code is not located at the root folder, you can specify this path here. 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: @@ -295,7 +296,7 @@ In general, _paramValues_ are tightly bound to Strategy _parameters_. Please mak #### Example -The [BuildKit sample `BuildStrategy`](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml) contains various parameters. Two of them are outlined here: +The [BuildKit sample `BuildStrategy`](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml) contains various parameters. Two of them are outlined here: ```yaml apiVersion: shipwright.io/v1beta1 @@ -634,13 +635,13 @@ spec: Annotations added to the output image can be verified by running the command: -```bash +```sh docker manifest inspect us.icr.io/source-to-image-build/nodejs-ex | jq ".annotations" ``` You can verify which labels were added to the output image that is available on the host machine by running the command: -```bash +```sh docker inspect us.icr.io/source-to-image-build/nodejs-ex | jq ".[].Config.Labels" ``` diff --git a/content/docs/build/buildstrategies.md b/content/docs/build/buildstrategies.md index 5c25b258..7e74cb8d 100644 --- a/content/docs/build/buildstrategies.md +++ b/content/docs/build/buildstrategies.md @@ -16,18 +16,18 @@ A `ClusterBuildStrategy` is available cluster-wide, while a `BuildStrategy` is a ## Available ClusterBuildStrategies -Well-known strategies can be bootstrapped from [here](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy). The currently supported Cluster BuildStrategy are: +Well-known strategies can be bootstrapped from [here](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy). The currently supported Cluster BuildStrategy are: | Name | Supported platforms | |-------------------------------------------------------------------------------------------------------------------|---------------------| -| [buildah](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/buildah) | all | -| [multiarch-native-buildah](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/multiarch-native-buildah) | all | -| [BuildKit](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/buildkit) | all | -| [buildpacks-v3-heroku](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_cr.yaml) | linux/amd64 only | -| [buildpacks-v3](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml) | linux/amd64 only | -| [kaniko](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/kaniko) | all | -| [ko](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/ko) | all | -| [source-to-image](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/source-to-image) | linux/amd64 only | +| [buildah](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/buildah) | all | +| [multiarch-native-buildah](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/multiarch-native-buildah) | all | +| [BuildKit](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/buildkit) | all | +| [buildpacks-v3-heroku](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_cr.yaml) | linux/amd64 only | +| [buildpacks-v3](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml) | linux/amd64 only | +| [kaniko](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/kaniko) | all | +| [ko](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/ko) | all | +| [source-to-image](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/source-to-image) | linux/amd64 only | ## Available BuildStrategies @@ -35,8 +35,8 @@ The current supported namespaces BuildStrategy are: | Name | Supported platforms | |------------------------------------------------------------------------------------------------------------------------------|---------------------| -| [buildpacks-v3-heroku](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_namespaced_cr.yaml) | linux/amd64 only | -| [buildpacks-v3](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_namespaced_cr.yaml) | linux/amd64 only | +| [buildpacks-v3-heroku](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3-heroku_namespaced_cr.yaml) | linux/amd64 only | +| [buildpacks-v3](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_namespaced_cr.yaml) | linux/amd64 only | --- @@ -46,8 +46,8 @@ The `buildah` ClusterBuildStrategy uses [`buildah`](https://github.com/container The strategy is available in two formats: -- [`buildah-shipwright-managed-push`](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml) -- [`buildah-strategy-managed-push`](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_strategy_managed_push_cr.yaml) +- [`buildah-shipwright-managed-push`](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml) +- [`buildah-strategy-managed-push`](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_strategy_managed_push_cr.yaml) Learn more about the differences of [shipwright-, or strategy-managed push](#output-directory-vs-output-image) @@ -55,7 +55,7 @@ Learn more about the differences of [shipwright-, or strategy-managed push](#out To install use: -```bash +```sh kubectl apply -f samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml kubectl apply -f samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_strategy_managed_push_cr.yaml ``` @@ -64,7 +64,7 @@ kubectl apply -f samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_str ## Multi-arch Native buildah -The [`multiarch-native-buildah` ClusterBuildStrategy](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/multiarch-native-buildah/buildstrategy_multiarch_native_buildah_cr.yaml) uses [`buildah`](https://github.com/containers/buildah) to build and push a container image, out of a `Dockerfile`. +The [`multiarch-native-buildah` ClusterBuildStrategy](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/multiarch-native-buildah/buildstrategy_multiarch_native_buildah_cr.yaml) uses [`buildah`](https://github.com/containers/buildah) to build and push a container image, out of a `Dockerfile`. The strategy will build the image for the platforms that are listed in the `architectures` parameter of a `Build` object that refers it. @@ -88,15 +88,29 @@ Finally, when running in OKD or OpenShift clusters, the service account must be To install the cluster-scoped strategy, use: -```bash +```sh kubectl apply -f samples/v1beta1/buildstrategy/multiarch-native-buildah/buildstrategy_multiarch_native_buildah_cr.yaml +kubectl apply -f samples/v1beta1/buildstrategy/multiarch-native-buildah/clusterrole_multiarch_native_buildah_cr.yaml ``` For each namespace where you want to use the strategy, you also need to apply the RBAC rules that allow the service account to run the strategy. If the service account is named `pipeline` (default), you can use: -```bash -kubectl apply -n -f samples/v1beta1/buildstrategy/multiarch-native-buildah/ +```sh +kubectl apply -n -f samples/v1beta1/buildstrategy/multiarch-native-buildah/rolebinding_multiarch_native_buildah_cr.yaml +``` + +_note_: If `pipeline` service account isn't available in your environment (most likely when using a kind cluster), replace the subjects[0].name to `default`. + +```sh +sed 's/name: pipeline/name: default/' samples/v1beta1/buildstrategy/multiarch-native-buildah/rolebinding_multiarch_native_buildah_cr.yaml| kubectl apply -f - +``` + +If you are on OKD platform, apply the following RBAC to use the +`privileged` SecurityContextConstraint: + +```sh +kubectl apply -f samples/v1beta1/buildstrategy/multiarch-native-buildah/rolebinding_multiarch_native_buildah_scc_okd_cr.yaml ``` ### Parameters @@ -176,7 +190,7 @@ You can install the `BuildStrategy` in your namespace or install the `ClusterBui To install the cluster scope strategy, you can choose between the Paketo and Heroku buildpacks family: -```bash +```sh # Paketo kubectl apply -f samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml @@ -186,7 +200,7 @@ kubectl apply -f samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_build To install the namespaced scope strategy, you can choose between the Paketo and Heroku buildpacks family: -```bash +```sh # Paketo kubectl apply -f samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_namespaced_cr.yaml @@ -204,7 +218,7 @@ The `kaniko` ClusterBuildStrategy is composed by Kaniko's `executor` [kaniko], w To install the cluster scope strategy, use: -```bash +```sh kubectl apply -f samples/v1beta1/buildstrategy/kaniko/buildstrategy_kaniko_cr.yaml ``` @@ -248,7 +262,7 @@ _Please note:_ At this point in time, there is no way to run `rootlesskit` to st To install the cluster scope strategy, use: -```bash +```sh kubectl apply -f samples/v1beta1/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml ``` @@ -262,7 +276,7 @@ The `ko` ClusterBuilderStrategy is using [ko](https://github.com/ko-build/ko)'s To install the cluster scope strategy, use: -```bash +```sh kubectl apply -f samples/v1beta1/buildstrategy/ko/buildstrategy_ko_cr.yaml ``` @@ -273,7 +287,7 @@ The build strategy provides the following parameters that you can set in a Build | Parameter | Description | Default | |---------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------| | `go-flags` | Value for the GOFLAGS environment variable. | Empty | -| `go-version` | Version of Go, must match a tag from [the golang image](https://hub.docker.com/_/golang?tab=tags) | `1.22` | +| `go-version` | Version of Go, must match a tag from [the golang image](https://hub.docker.com/_/golang?tab=tags) | `1.24` | | `ko-version` | Version of ko, must be either `latest` for the newest release, or a [ko release name](https://github.com/ko-build/ko/releases) | `latest` | | `package-directory` | The directory inside the context directory containing the main package. | `.` | | `target-platform` | Target platform to be built. For example: `linux/arm64`. Multiple platforms can be provided separated by comma, for example: `linux/arm64,linux/amd64`. The value `all` will build all platforms supported by the base image. The value `current` will build the platform on which the build runs. | `current` | @@ -294,7 +308,7 @@ This BuildStrategy is composed by [`source-to-image`][s2i] and [`kaniko`][kaniko To install the cluster scope strategy use: -```bash +```sh kubectl apply -f samples/v1beta1/buildstrategy/source-to-image/buildstrategy_source-to-image_cr.yaml ``` @@ -320,7 +334,7 @@ Users defining _parameters_ under their strategies require to understand the fol - **Definition**: A list of parameters should be defined under `spec.parameters`. Each list item should consist of a _name_, a _description_, a _type_ (either `"array"` or `"string"`) and optionally a _default_ value (for type=string), or _defaults_ values (for type=array). If no default(s) are provided, then the user must define a value in the Build or BuildRun. - **Usage**: In order to use a parameter in the strategy steps, use the following syntax for type=string: `$(params.your-parameter-name)`. String parameters can be used in all places in the `buildSteps`. Some example scenarios are: - - `image`: to use a custom tag, for example `golang:$(params.go-version)` as it is done in the [ko sample build strategy](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/ko/buildstrategy_ko_cr.yaml) + - `image`: to use a custom tag, for example `golang:$(params.go-version)` as it is done in the [ko sample build strategy](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/ko/buildstrategy_ko_cr.yaml) - `args`: to pass data into your builder command - `env`: to force a user to provide a value for an environment variable. @@ -356,7 +370,7 @@ Users defining _parameters_ under their strategies require to understand the fol **Note**: Users can provide parameter values as simple strings or as references to keys in [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/) and [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/). If they use a ConfigMap or Secret, then the value can only be used if the parameter is used in the `command`, `args`, or `env` section of the `buildSteps`. For example, the above-mentioned scenario to set a step's `image` to `golang:$(params.go-version)` does not allow the usage of ConfigMaps or Secrets. -The following example is from the [BuildKit sample build strategy](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml). It defines and uses several parameters: +The following example is from the [BuildKit sample build strategy](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildkit/buildstrategy_buildkit_cr.yaml). It defines and uses several parameters: ```yaml --- @@ -390,7 +404,7 @@ spec: steps: ... - name: build-and-push - image: moby/buildkit:v0.17.0-rootless + image: moby/buildkit:v0.26.2-rootless imagePullPolicy: Always workingDir: $(params.shp-source-root) ... @@ -445,7 +459,7 @@ spec: # using head because the data could be multiline id="$(echo "${a}" | head -1 | sed 's/=.*//')" - # This is hacky, we remove the suffix ${id}= from all lines of the data. + # This is hacky, we remove the prefix ${id}= from all lines of the data. # If the data would be multiple lines and a line would start with ${id}= # then we would remove it. We could force users to give us the secret # base64 encoded. But ultimately, the best solution might be if the user @@ -501,7 +515,7 @@ When you use the `$(params.shp-output-directory)` parameter, then Shipwright wil If you are uncertain about how to implement your build strategy, then follow this guidance: -1. If your build strategy tool cannot locally store an image but always pushes it, then you must do the push operation. An example is the [Buildpacks strategy](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml). You SHOULD respect the `$(params.shp-output-insecure)` parameter. +1. If your build strategy tool cannot locally store an image but always pushes it, then you must do the push operation. An example is the [Buildpacks strategy](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml). You SHOULD respect the `$(params.shp-output-insecure)` parameter. 2. If your build strategy tool can locally store an image, then the choice depends on how you expect your build users to make use of your strategy, and the nature of your strategy. 1. Some build strategies do not produce all layers of an image, but use a common base image and put one or more layers on top with the application. An example is `ko`. Such base image layers are often already present in the destination registry (like in rebuilds). If the strategy can perform the push operation, then it can optimize the process and can omit the download of the base image when it is not required to push it. In the case of a shipwright-managed push, the complete image must be locally stored in `$(params.shp-output-directory)`, which implies that a base image must always be downloaded. 2. Some build strategy tools do not make it easy to determine the digest or size of the image, which can make it complex for you to set the [strategy results](#system-results). In the case of a shipwright-managed push, Shipwright has the responsibility to set them. @@ -548,7 +562,7 @@ This opens the door to script injection, for example if the user sets the `sampl To securely pass a parameter value into a script-style argument, you can choose between these two approaches: -1. Using environment variables. This is used in some of our sample strategies, for example [ko](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/ko/buildstrategy_ko_cr.yaml), or [buildpacks](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml). Basically, instead of directly using the parameter inside the script, you pass it via environment variable. Using quoting, shells ensure that no command injection is possible: +1. Using environment variables. This is used in some of our sample strategies, for example [ko](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/ko/buildstrategy_ko_cr.yaml), or [buildpacks](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml). Basically, instead of directly using the parameter inside the script, you pass it via environment variable. Using quoting, shells ensure that no command injection is possible: ```yaml spec: @@ -571,7 +585,7 @@ To securely pass a parameter value into a script-style argument, you can choose some-tool --sample-argument "${PARAM_SAMPLE_PARAMETER}" ``` -2. Using arguments. This is used in some of our sample build strategies, for example [buildah](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml). Here, you use arguments to your own inline script. Appropriate shell quoting guards against command injection. +2. Using arguments. This is used in some of our sample build strategies, for example [buildah](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml). Here, you use arguments to your own inline script. Appropriate shell quoting guards against command injection. ```yaml spec: @@ -604,7 +618,7 @@ If you are using a strategy-managed push, see [output directory vs output image] | `$(results.shp-image-digest.path)` | File to store the digest of the image. | | `$(results.shp-image-size.path)` | File to store the compressed size of the image. | -You can look at sample build strategies, such as [Buildpacks](https://github.com/shipwright-io/build/blob/v0.15.2/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml), to see how they fill some or all of the results files. +You can look at sample build strategies, such as [Buildpacks](https://github.com/shipwright-io/build/blob/v0.18.0/samples/v1beta1/buildstrategy/buildpacks-v3/buildstrategy_buildpacks-v3_cr.yaml), to see how they fill some or all of the results files. This information will be available in the `.status.output` section of the BuildRun. @@ -680,7 +694,7 @@ metadata: spec: steps: - name: build-and-push - image: gcr.io/kaniko-project/executor:v1.23.2 + image: gcr.io/kaniko-project/executor:v1.24.0 workingDir: $(params.shp-source-root) securityContext: runAsUser: 0 @@ -729,7 +743,7 @@ metadata: spec: steps: - name: build-and-push - image: gcr.io/kaniko-project/executor:v1.23.2 + image: gcr.io/kaniko-project/executor:v1.24.0 workingDir: $(params.shp-source-root) securityContext: runAsUser: 0 @@ -811,15 +825,15 @@ For a more concrete example, let´s take a look on the following scenarios: If we apply the following resources: -- [buildahBuild](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/build/build_buildah_shipwright_managed_push_cr.yaml) -- [buildahBuildRun](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildrun/buildrun_buildah_cr.yaml) -- [buildahClusterBuildStrategy](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml) +- [buildahBuild](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/build/build_buildah_shipwright_managed_push_cr.yaml) +- [buildahBuildRun](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildrun/buildrun_buildah_cr.yaml) +- [buildahClusterBuildStrategy](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml) We will see some differences between the `TaskRun` definition and the `pod` definition. -For the `TaskRun`, as expected we can see the resources on each `step`, as we previously define on our [strategy](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml). +For the `TaskRun`, as expected we can see the resources on each `step`, as we previously define on our [strategy](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildstrategy/buildah/buildstrategy_buildah_shipwright_managed_push_cr.yaml). -```bash +```sh $ kubectl -n test-build get tr buildah-golang-buildrun-9gmcx-pod-lhzbc -o json | jq '.spec.taskSpec.steps[] | select(.name == "step-buildah-bud" ) | .resources' { "limits": { @@ -847,7 +861,7 @@ $ kubectl -n test-build get tr buildah-golang-buildrun-9gmcx-pod-lhzbc -o json | The pod definition is different, while Tekton will only use the **highest** values of one container, and set the rest(lowest) to zero: -```bash +```sh $ kubectl -n test-build get pods buildah-golang-buildrun-9gmcx-pod-lhzbc -o json | jq '.spec.containers[] | select(.name == "step-step-buildah-bud" ) | .resources' { "limits": { @@ -883,13 +897,13 @@ In this scenario, only one container can have the `spec.resources.requests` defi If we apply the following resources: -- [buildahBuild](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/build/build_buildah_shipwright_managed_push_cr.yaml) -- [buildahBuildRun](https://github.com/shipwright-io/build/tree/v0.15.2/samples/v1beta1/buildrun/buildrun_buildah_cr.yaml) +- [buildahBuild](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/build/build_buildah_shipwright_managed_push_cr.yaml) +- [buildahBuildRun](https://github.com/shipwright-io/build/tree/v0.18.0/samples/v1beta1/buildrun/buildrun_buildah_cr.yaml) - We will use a modified buildah strategy, with the following steps resources: ```yaml - name: buildah-bud - image: quay.io/containers/buildah:v1.37.5 + image: quay.io/containers/buildah:v1.42.1 workingDir: $(params.shp-source-root) securityContext: privileged: true @@ -911,7 +925,7 @@ If we apply the following resources: - name: buildah-images mountPath: /var/lib/containers/storage - name: buildah-push - image: quay.io/containers/buildah:v1.37.5 + image: quay.io/containers/buildah:v1.42.1 securityContext: privileged: true command: @@ -931,7 +945,7 @@ If we apply the following resources: For the `TaskRun`, as expected we can see the resources on each `step`. -```bash +```sh $ kubectl -n test-build get tr buildah-golang-buildrun-skgrp -o json | jq '.spec.taskSpec.steps[] | select(.name == "step-buildah-bud" ) | .resources' { "limits": { @@ -959,7 +973,7 @@ $ kubectl -n test-build get tr buildah-golang-buildrun-skgrp -o json | jq '.spec The pod definition is different, while Tekton will only use the **highest** values of one container, and set the rest(lowest) to zero: -```bash +```sh $ kubectl -n test-build get pods buildah-golang-buildrun-95xq8-pod-mww8d -o json | jq '.spec.containers[] | select(.name == "step-step-buildah-bud" ) | .resources' { "limits": { diff --git a/content/docs/build/configuration.md b/content/docs/build/configuration.md index fc8b98a2..beafda09 100644 --- a/content/docs/build/configuration.md +++ b/content/docs/build/configuration.md @@ -18,13 +18,13 @@ The following environment variables are available: | `REMOTE_ARTIFACTS_CONTAINER_IMAGE` | Specify the container image used for the `.spec.sources` remote artifacts download, by default it uses `quay.io/quay/busybox:latest`. | | `TERMINATION_LOG_PATH` | Path of the termination log. This is where controller application will write the reason of its termination. Default value is `/dev/termination-log`. | | `GIT_ENABLE_REWRITE_RULE` | Enable Git wrapper to setup a URL `insteadOf` Git config rewrite rule for the respective source URL hostname. Default is `false`. | -| `GIT_CONTAINER_TEMPLATE` | JSON representation of a [Container] template that is used for steps that clone a Git repository. Default is `{"image": "ghcr.io/shipwright-io/build/git:latest", "command": ["/ko-app/git"], "env": [{"name": "HOME", "value": "/shared-home"},{"name": "GIT_SHOW_LISTING", "value": "false"}], "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser": 1000,"runAsGroup": 1000}}` [^1]. The following properties are ignored as they are set by the controller: `args`, `name`. | +| `GIT_CONTAINER_TEMPLATE` | JSON representation of a [Container] template that is used for steps that clone a Git repository. Default is `{"image": "ghcr.io/shipwright-io/build/git:latest", "command": ["/ko-app/git"], "env": [{"name": "HOME", "value": "/shared-home"},{"name": "GIT_SHOW_LISTING", "value": "false"}], "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser": 1000,"runAsGroup": 1000}, "readOnlyRootFilesystem": true}` [^1]. The following properties are ignored as they are set by the controller: `args`, `name`. | | `GIT_CONTAINER_IMAGE` | Custom container image for Git clone steps. If `GIT_CONTAINER_TEMPLATE` is also specifying an image, then the value for `GIT_CONTAINER_IMAGE` has precedence. | -| `BUNDLE_CONTAINER_TEMPLATE` | JSON representation of a [Container] template that is used for steps that pulls a bundle image to obtain the packaged source code. Default is `{"image": "ghcr.io/shipwright-io/build/bundle:latest", "command": ["/ko-app/bundle"], "env": [{"name": "HOME","value": "/shared-home"},{"name": "BUNDLE_SHOW_LISTING","value": "false"}], "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser":1000,"runAsGroup":1000}}` [^1]. The following properties are ignored as they are set by the controller: `args`, `name`. | +| `BUNDLE_CONTAINER_TEMPLATE` | JSON representation of a [Container] template that is used for steps that pulls a bundle image to obtain the packaged source code. Default is `{"image": "ghcr.io/shipwright-io/build/bundle:latest", "command": ["/ko-app/bundle"], "env": [{"name": "HOME","value": "/shared-home"},{"name": "BUNDLE_SHOW_LISTING","value": "false"}], "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser":1000,"runAsGroup":1000}, "readOnlyRootFilesystem": true}` [^1]. The following properties are ignored as they are set by the controller: `args`, `name`. | | `BUNDLE_CONTAINER_IMAGE` | Custom container image that pulls a bundle image to obtain the packaged source code. If `BUNDLE_IMAGE_CONTAINER_TEMPLATE` is also specifying an image, then the value for `BUNDLE_IMAGE_CONTAINER_IMAGE` has precedence. | -| `IMAGE_PROCESSING_CONTAINER_TEMPLATE` | JSON representation of a [Container](https://pkg.go.dev/k8s.io/api/core/v1#Container) template that is used for steps that processes the image. Default is `{"image": "ghcr.io/shipwright-io/build/image-processing:latest", "command": ["/ko-app/image-processing"], "env": [{"name": "HOME","value": "/shared-home"}], "securityContext": {"allowPrivilegeEscalation": false, "capabilities": {"add": ["DAC_OVERRIDE"], "drop": ["ALL"]}, "runAsUser": 0, "runAsgGroup": 0}}`. The following properties are ignored as they are set by the controller: `args`, `name`. | +| `IMAGE_PROCESSING_CONTAINER_TEMPLATE` | JSON representation of a [Container](https://pkg.go.dev/k8s.io/api/core/v1#Container) template that is used for steps that processes the image. Default is `{"image": "ghcr.io/shipwright-io/build/image-processing:latest", "command": ["/ko-app/image-processing"], "env": [{"name": "HOME","value": "/shared-home"}], "securityContext": {"allowPrivilegeEscalation": false, "capabilities": {"add": ["DAC_OVERRIDE"], "drop": ["ALL"]}, "runAsUser": 0, "runAsgGroup": 0}, "readOnlyRootFilesystem": true}`. The following properties are ignored as they are set by the controller: `args`, `name`. | | `IMAGE_PROCESSING_CONTAINER_IMAGE` | Custom container image that is used for steps that processes the image. If `IMAGE_PROCESSING_CONTAINER_TEMPLATE` is also specifying an image, then the value for `IMAGE_PROCESSING_CONTAINER_IMAGE` has precedence. | -| `WAITER_CONTAINER_TEMPLATE` | JSON representation of a [Container] template that waits for local source code to be uploaded to it. Default is `{"image":"ghcr.io/shipwright-io/build/waiter:latest", "command": ["/ko-app/waiter"], "args": ["start"], "env": [{"name": "HOME","value": "/shared-home"}], "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser":1000,"runAsGroup":1000}}`. The following properties are ignored as they are set by the controller: `args`, `name`. | +| `WAITER_CONTAINER_TEMPLATE` | JSON representation of a [Container] template that waits for local source code to be uploaded to it. Default is `{"image":"ghcr.io/shipwright-io/build/waiter:latest", "command": ["/ko-app/waiter"], "args": ["start","--lock-file=/shp-tmp/waiter.lock"], "env": [{"name": "HOME","value": "/shared-home"}], "securityContext":{"allowPrivilegeEscalation": false, "capabilities": {"drop": ["ALL"]}, "runAsUser":1000,"runAsGroup":1000}, "readOnlyRootFilesystem": true}`. The following properties are ignored as they are set by the controller: `args`, `name`. | | `WAITER_CONTAINER_IMAGE` | Custom container image that waits for local source code to be uploaded to it. If `WAITER_IMAGE_CONTAINER_TEMPLATE` is also specifying an image, then the value for `WAITER_IMAGE_CONTAINER_IMAGE` has precedence. | | `BUILD_CONTROLLER_LEADER_ELECTION_NAMESPACE` | Set the namespace to be used to store the `shipwright-build-controller` lock, by default it is in the same namespace as the controller itself. | | `BUILD_CONTROLLER_LEASE_DURATION` | Override the `LeaseDuration`, which is the duration that non-leader candidates will wait to force acquire leadership. | @@ -37,6 +37,7 @@ The following environment variables are available: | `KUBE_API_BURST` | Burst to use for the Kubernetes API client. See [Config.Burst]. A value of 0 or lower will use the default from client-go, which currently is 10. Default is 0. | | `KUBE_API_QPS` | QPS to use for the Kubernetes API client. See [Config.QPS]. A value of 0 or lower will use the default from client-go, which currently is 5. Default is 0. | | `VULNERABILITY_COUNT_LIMIT` | holds vulnerability count limit if vulnerability scan is enabled for the output image. If it is defined as 10, then it will output only 10 vulnerabilities sorted by severity in the buildrun status.Output. Default is 50. | +| `BUILDRUN_EXECUTOR` | Sets the kind of buildrun exectutor that will be used. Value can be `TaskRun` or `PipelineRun`. By default buildrun will use `TaskRun` for its build executor. | [^1]: The `runAsUser` and `runAsGroup` are dynamically overwritten depending on the build strategy that is used. See [Security Contexts](../buildstrategies#security-contexts) for more information. diff --git a/content/docs/getting-started/installation.md b/content/docs/getting-started/installation.md index 0cacd847..cd12345a 100644 --- a/content/docs/getting-started/installation.md +++ b/content/docs/getting-started/installation.md @@ -10,8 +10,8 @@ with our operator. ## Prerequisites -- [Kubernetes](https://kubernetes.io/) 1.29 or later. -- [Tekton pipelines](https://tekton.dev/docs/installation/) v0.59 or later. +- [Kubernetes](https://kubernetes.io/) 1.32 or later. +- [Tekton pipelines](https://tekton.dev/docs/installation/) v0.68 or later. ```bash kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml