Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 1. Overview of Builds

Builds is a Shipwright-based framework for building container images on OpenShift Container Platform. It is designed for developers seeking automated image creation and administrators managing secure, reusable build strategies at scale.

1.1. Builds capabilities and resources
Copier lien

Builds provides Kubernetes-native APIs to build container images from source code and Dockerfiles. It supports S2I and Buildah strategies, allows custom build strategies, executes builds from local directories, offers a CLI for managing builds, and integrates with the Developer perspective of the OpenShift Container Platform console.

Builds consists of the following custom resources (CRs):

  • Build
  • BuildStrategy and ClusterBuildStrategy
  • BuildRun

1.1.1. Build resource
Copier lien

The Build resource defines the source code of your application and the location where your application images will be pushed. The following example shows a simple build that consists of a Git source, a build strategy, and an output image: 

apiVersion: shipwright.io/v1beta1
kind: Build
metadata:
  name: buildah-golang-build
spec:
  source:
    git:
      url: https://github.com/username/taxi
  strategy:
    name: buildah
    kind: ClusterBuildStrategy
  output:
    image: registry.mycompany.com/my-org/taxi-app:latest

You can also extend a Build resource to push your images to a private registry or use a Dockerfile.

1.1.2. BuildStrategy and ClusterBuildStrategy resources
Copier lien

The BuildStrategy and ClusterBuildStrategy resources define the steps needed to build an application.

A BuildStrategy is namespace-scoped and can be created, managed, and used only within a specific namespace and not shared across the cluster.

A ClusterBuildStrategy is cluster-scoped and can be shared across namespaces.

Both resources include a steps section. The following example shows a ClusterBuildStrategy named buildah. 

apiVersion: shipwright.io/v1beta1
kind: ClusterBuildStrategy
metadata:
  name: buildah
spec:
  steps:
    - name: build-and-push
      image: quay.io/containers/buildah:v1.31.0
      workingDir: $(params.shp-source-root)
      command:
        - /bin/bash
       # ...
# ...

1.1.3. BuildRun resource
Copier lien

A BuildRun resource invokes a build on the cluster similar to a Tekton task run. It represents a workload that instantiates a build for execution with specific parameters. Each BuildRun defines a unique name for monitoring, references a Build instance, and specifies a service account within a namespace.

A BuildRun resource helps you to define the following elements:

  • A unique BuildRun name to monitor the status of the build
  • A referenced Build instance to use during the build
  • A service account to host all secrets for the build

Each BuildRun resource is available within a namespace.

1.1.4. Build controller
Copier lien

The build controller monitors any updates in the Build resource and performs the following tasks:

  • Validates if the referenced Strategy object exists in the Build resource.
  • Validates if the specified parameters in the Build CR exist in the referenced build strategy. It also validates if the parameter names collide with any reserved names.
  • Validates if the container registry output secret exists in the Build resource.
  • Validates if the referenced spec.source.git.url endpoint URL exists in the Build resource.

The build run controller monitors any updates in the Build or TaskRun resource and performs the following tasks:

  • Searches for any existing TaskRun resource and updates its parent BuildRun resource status.
  • Retrieves the specified service account and sets it along with the output secret in the Build resource.
  • If a TaskRun resource does not exist, the controller generates a new Tekton TaskRun resource and sets a reference to the TaskRun resource.
  • For any subsequent updates in the TaskRun resource, the controller updates the parent BuildRun resource.

1.1.5. Build validations
Copier lien

The build controller validates BuildRun resources in advance to prevent failures from incorrect or missing dependencies and configuration settings. Validations check for strategy existence, secret references, parameter definitions, Git repository accessibility, and environment variable completeness.

Expand
Table 1.1. Validation of builds by the build controller
status.reason fieldDescription

BuildStrategyNotFound

The referenced strategy at namespace level does not exist.

ClusterBuildStrategyNotFound

The referenced strategy at cluster level does not exist.

SetOwnerReferenceFailed

Setting owner references between a Build and a BuildRun resources failed. This status is triggered when you set the spec.retention.atBuildDeletion field to true in a build.

SpecSourceSecretRefNotFound

The secret used to authenticate to Git does not exist.

SpecOutputSecretRefNotFound

The secret used to authenticate to the container registry does not exist.

SpecBuilderSecretRefNotFound

The secret used to authenticate to the container registry does not exist.

MultipleSecretRefNotFound

Multiple secrets used for authentication are missing.

RestrictedParametersInUse

One or many defined params are colliding with any reserved parameters.

UndefinedParameter

The parameters are not defined in the referenced strategy. You must define those parameters in the spec.parameters specification in your strategy.

RemoteRepositoryUnreachable

The defined spec.source.git.url specification was not found. This validation only takes place for HTTP and HTTPS protocols.

BuildNameInvalid

The build name in the metadata.name field is invalid. You must use a valid label value for the build name.

SpecEnvNameCanNotBeBlank

Indicates that the name for a user-provided environment variable is blank.

SpecEnvValueCanNotBeBlank

Indicates that the value for a user-provided environment variable is blank.

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début