-
stable-v1
-
openshift-builds-1.0
Release notes contain information about new and deprecated features, breaking changes, and known issues. The following release notes apply for the most recent Builds releases on OpenShift Container Platform.
Builds is an extensible build framework based on the Shipwright project, which you can use to build container images on an OpenShift Container Platform cluster. You can build container images from source code and Dockerfiles by using image build tools, such as Source-to-Image (S2I) and Buildah. You can create and apply build resources, view logs of build runs, and manage builds in your OpenShift Container Platform namespaces.
Builds includes the following capabilities:
Standard Kubernetes-native API for building container images from source code and Dockerfiles
Support for Source-to-Image (S2I) and Buildah build strategies
Extensibility with your own custom build strategies
Execution of builds from source code in a local directory
Shipwright CLI for creating and viewing logs, and managing builds on the cluster
Integrated user experience with the Developer perspective of the OpenShift Container Platform web console
For more information about Builds, see Overview of Builds.
In the table, components are marked with the following statuses:
TP |
Technology Preview |
GA |
General Availability |
The Technology Preview features are experimental features and are not intended for production use.
Builds Version | Component Version | Compatible Openshift Pipelines Version | OpenShift Version | Support | |
---|---|---|---|---|---|
Operator |
Builds (Shipwright) |
CLI |
|||
1.3 |
0.14.0 (GA) |
0.14.0 (GA) |
1.14, 1.15, 1.16, 1.17 |
4.14, 4.15, 4.16, 4.17 |
GA |
1.2 |
0.13.0 (GA) |
0.13.0 (GA) |
1.14, 1.15, 1.16 |
4.12, 4.13, 4.14, 4.15, 4.16, 4.17 |
GA |
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.
With this update, Builds 1.3 is now Generally Available (GA) on OpenShift Container Platform 4.14, 4.15, 4.16, and 4.17.
The following section highlights what is new in Builds 1.3.
With this update, the Builds for Red Hat OpenShift Operator deploys Shipwright v0.14 APIs, controllers, and webhook.
With this update, while creating the Build
or BuildRun
resources with OpenShift Builds Client, you can set the parameters by using the --param-value
flag.
The following section highlights fixed issues in Builds 1.3.
Before this update, when you installed Builds without installing OpenShift Pipelines, the Builds attempted to deploy OpenShift Pipelines and enable Pipelines controllers. Builds incorrectly configured OpenShift Pipelines and failed to deploy the controllers. With this update, Builds creates a valid TektonConfig
custom resource and correctly deploys the Pipelines controllers.
Before this update, when you tried to run builds using builds for Red Hat OpenShift installed on ARM64, IBM Power®, or IBM Z® worker node CPU architectures, the build would fail because images were based on AMD64 platform only. Now, the AMD64 images are replaced with a multi-arch
image in buildah
and source-to-image
build strategies, therefore you can run builds on all the architectures.
Before this update, when you enabled cluster monitoring in the openshift-builds
namespace, the TargetDown
alert was received on the Shared Resources Container Storage Interface (CSI) Driver ServiceMonitor
resource due to an incorrect server name address. With this update, the server name is updated to the correct address in the Shared Resources CSI Driver ServiceMonitor
resource and the TargetDown
alert is no longer triggered.
Before this update, the Operator logo was not displayed in the OperatorHub. To display the Operator logo in the OperatorHub, you had to update the logo in the File Based Catalog (FBC) catalog format even after specifying it in the CSV file. With this update, the Operator logo data is specified in the catalog config.yaml
files and the logo is displayed in the OperatorHub.