OpenShift Build Operations
Internal
Overview
Build and Deploy a JEE Application
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.
Source Build
Before declaring the build configuration, define an image stream that will provide the builder image, as shown here:
The build configuration and associated objects is created with:
oc new-build \ [--dry-run] \ --strategy=source \ --image-stream=eap7 \ [--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.
Docker Build
TODO
--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.
Pipeline Build
TODO
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 lists that trigger.
Source repository configuration:
Build configuration:
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.