OpenShift Build Operations

Internal

• OpenShift Operations
• OpenShift Concepts
• Deployment Operations

Overview

Builds

Build and Deploy a JEE Application

Build and Deploy a JEE Application with S2I

Create a Build Configuration

oc new-build is the preferred way to create a new build configuration. oc new-app also creates a build configuration, and for an example of how to do so, see Build and Deploy a JEE Application. The following considerations apply to all types of builds (source, docker and pipeline) that can be created with oc new-build:

• --dry-run can be used to visualize the results of the operation, without modifying anything on the master server.

Docker Build

--binary=true makes sure that restrictions associated with binary builds are enforced. It says that instead of expecting a source URL, set the build to expect binary contents. Will disable triggers.

cp target/session-servlet.war oc-build/deployments
oc new-build --binary=true --name=noss-dev --labels=app=noss-dev --image-stream=jboss-eap70-openshift:1.5 
oc start-build noss-dev --from-dir=oc-build --wait=true

Also see:

Docker Build

Source Build

Before declaring the build configuration, define an image stream that will provide the builder image, as shown here:

Create an Image Stream

Use a definition similar to:

apiVersion: v1
kind: ImageStream
metadata:
  name: eap7-builder-image
spec:
  tags:
  - name: latest
    from:
      kind: DockerImage
      name: registry.access.redhat.com/jboss-eap-7/eap70-openshift:latest

The source build configuration and associated objects is created with:

oc new-build \
  [--dry-run] \
  --strategy=source \
  --image-stream=<builder-image-image-stream> \
  [--name=app-name] \
  https://gogs-cicd.apps.openshift.novaordis.io/gogs/novaordis-session-servlet.git

This will create the build configuration and the image stream for the artifacts. Immediately after the build configuration is declared, a build starts, and if it successful, a new image will be pushed into the artifact image stream.

The following issued may occur during the build configuration creation and the subsequent first build attempt:

• If the application name is not specified with --name, it will default to current project name.
• The command shallow clones the specified repository locally, so if the repository certificate is self-signed, which is almost always the case with internal repositories, it will complain. SSL certificate verification can be turned off as described here: turn off SSL server certificate verification.
• If the repository uses self-signed certificate, the build pod will fail the same way while attempting to clone. This is fixed by adding the GIT_SSL_NO_VERIFY=true Git environment variable to the build configuration spec.strategy.sourceStrategy.env, as describe here: turn off SSL server certificate for Git in a build pod.

The full application template that creates all objects required for a S2I build and subsequent deployment is available here:

https://github.com/NovaOrdis/playground/blob/master/openshift/templates/eap7-application-s2i-template.yaml

Pipeline Build

• Git SSL verification: if the repository uses self-signed certificate, the build pod will fail while attempting to clone. This is fixed by adding the GIT_SSL_NO_VERIFY=true Git environment variable to the build configuration spec.strategy.jenkinsPipelineStrategy.env, as describe here: turn off SSL server certificate for Git in a build pod.

Creating a pipeline build configuration automatically deploys a Jenkins pod, service, route. etc. in the project.

Jenkins doesn’t have label agent

Alternative Pipeline Build Creation

TODO. Place a Jenkinsfile that defines the pipeline in the root of the source code repository.

The pipeline build configuration and associated objects is created with:

oc new-build [--dry-run] --strategy=pipeline https://gogs-cicd.apps.openshift.novaordis.io/gogs/novaordis-session-servlet.git

Source Clone Secret

oc set build-secret --source bc/<build-configuration-name'> <secret-name>

Then the secret can be added to the build configuration:

oc new-build .../example.git --build-secret <secret-name>

Set Maximum Duration

spec:
  completionDeadlineSeconds: 1800

Configure a Webhook Trigger for a Source Build

A build can be triggered by a push into the source repository, if the source repository was configured with a webhook, and the build configuration contains a webhook trigger with the correct secret. Source repository configuration:

• GitHub webhook configuration
• Gogs webhook configuration

Build configuration:

Enable a Generic Webhook Trigger

Manually Start the Build Process

 oc start-build <buildConfig-name>

The name of a previous build can be specified - it will be used as a starting point.

Options:

• --from-file
• --from-dir
• --from-repo
• --from-archive

View Builds for Project

oc get builds

NAME          TYPE      FROM          STATUS                    STARTED             DURATION
bookstore-1   Source    Git@ad0abda   Failed (AssembleFailed)   About an hour ago   2m43s
bookstore-2   Source    Git@ad0abda   Failed (AssembleFailed)   12 minutes ago      2m16s

Each build has an associated build pod, whose names can be obtained with:

oc get pods

NAME                      READY     STATUS    RESTARTS   AGE
bookstore-1-build         0/1       Error     0          57m
bookstore-2-build         0/1       Error     0          13m

View Build Logs

View build logs associated with a build object:

oc logs [-f] builds/<build-name>

If -f|--follow is used, it specifies that the logs should be streamed.

Viewing the build logs in this manner is similar to following the build pod's logs.

Stop a Build in Progress

oc cancel-build

Delete a Build

oc delete build/<build-name> 

where the build name is among those returned by oc get builds.

Delete a Build Configuration

oc delete bc/<build-configuration-name> 

Deleting a build configuration also deletes all associated builds and build pods.