OpenShift Build Operations
- 1 Internal
- 2 Overview
- 3 Build and Deploy a JEE Application
- 4 Create a Build Configuration
- 5 Manually Start the Build Process
- 6 View Builds for Project
- 7 View Build Logs
- 8 Stop a Build in Progress
- 9 Delete a Build
- 10 Delete a Build Configuration
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.
--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=trueAlso see:
Before declaring the build configuration, define an image stream that will provide the builder image, as shown here:
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:
- 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:
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.
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
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.