shipwright-io · SaschaSchwarze0 · Dec 1, 2025
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
@@ -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
@@ -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"
 ```