Binary Inputs for Jenkins Builds on OpenShift

February 10, 2020

Diving into the OpenShift Container Platform (OCP) is a challenge. One primary objective of our client was to host a Micro-Services Architecture (Spring Boot) on a Micro-Services Platform. Therefore OpenShift was acquired.

OpenShift provides with Jenkins CI an out of the box solution for a build infrastructure. Beginning to build your own software on OCP comes with multiple challenges. A lot of base knowledge for OpenShift (Docker and Kubernetes) and Jenkins is needed. That might be a little bit overwhelming. Especially finding a clear path is difficult under the vast documentation.

This blog post sheds some light on how to build software artefacts (Spring Boot executable JAR/WAR) with Jenkins and bundle them with Docker containers. OpenShift provides multiple build configurations.

For us, it is essential to distinguish between two types of builds.

  1. The Jenkins Pipeline build as a Jenkinsfile scripted in Groovy. We named it the Artifact build.
  2. The Docker Image build.

Bear in mind; we do an example with lots of variables. Our concern is to give you an understanding of the problem and our solution. You can use that as a jump start to solve or implement your builds with OpenShift and Jenkins. Our example used a persistent Jenkins instance on OpenShift.

Beginning with OpenShift Builds

In our first approach, we built the Artifact and deployed it to JFrog Artifactory as a cloud service. In the Docker build on OpenShift we queried Artifactory and retrieved the download URL for the Artifact.

Old Build Procedure

This approach has disadvantages:

Following Dockerfile was used for the docker image build.

FROM redhat-openjdk-18/openjdk18-openshift

ENV ARTIFACTORY_SERVER="" GROUP_ID="com.mimacom.ocp" ARTIFACT_ID="demo-app"

ARG JAVA_OPTS="-Xms384m -Xmx384m"

USER root

RUN yum install wget -y && yum clean all -y
RUN wget -O /usr/bin/jq && chmod a+rx /usr/bin/jq

RUN mkdir -p /srv/app/

RUN curl "$ARTIFACTORY_SERVER/api/search/gavc?g=$GROUP_ID&a=$ARTIFACT_ID&v=$ARTIFACT_VERSION&repos=libs-snapshots-local" -s > output.txt
RUN wget -O download.txt $(cat output.txt | /usr/bin/jq -r '.results[0].uri')
RUN wget -O /srv/app/micro-service.jar $(cat download.txt | /usr/bin/jq -r '.downloadUri')


ADD logback-spring.xml /srv/app/
RUN chmod 755 / && chmod g=u /etc/passwd && chown -R 1001:0 /srv/app


# OpenShift requires images to run as non-root by default
USER 1001

As you can see, there is much ugly logic scripted within the Dockerfile.

New Approach

Our desires or requirements:

We need to pass the Artifact directly to the Docker build. Our new approach passes the artifact directly to the Docker build.

Build Procedure


The solution is easy if you know all the possibilities.

See below the example configuration:

kind: BuildConfig
    name: micro-service-docker
    namespace: development
        build: micro-service
        app: micro-service
        binary: {}
            kind: ImageStreamTag
            name: micro-service:latest
            namespace: development
    postCommit: {}
    resources: {}
            dockerfilePath: ./openshift/Dockerfile
        type: Docker

With that change we can now use in the Jenkinsfile:

stage('Docker Build in development namespace') {
    steps {
        sh '''
            oc start-build -F $DOCKER_BUILD_NAME --from-dir . -n $DEV

As an alternative, you could also use this scripted syntax as an alternative to the declarative syntax.

stage('Docker Build in dev') {
   steps {
       script {
           openshift.withCluster() {
               openshift.withProject("development") {
                   // bc = build configuration ...
                   def build = openshift.selector('bc', 'micro-service-docker').startBuild("--from-dir .")

The above stage triggers the OpenShift Docker build. The Jenkins directory is zipped and uploaded to the pod that runs the docker build. In this pod, the archive contents are extracted. These example logs appear in the Jenkins output.

[logs:build/micro-service-docker-12] Receiving source from STDIN as archive ...
[logs:build/micro-service-docker-12] Step 1/15 : FROM redhat-openjdk-18/openjdk18-openshift

Instead of the previous complicated logic in the Dockerfile, you have now only one line. This line copies the built artifact into the Docker image.

COPY microservice-app/target/micro-service.jar /srv/app/micro-service.jar

After the successful build, you can trigger the deployment and verify it.

stage('Deploy to development') {
    steps {
            namespace: '$DEV',
            depCfg: '$DEPLOYMENT_CONFIG',
            waitTime: '300000'

            namespace: '$DEV',
            depCfg: '$DEPLOYMENT_CONFIG',
            replicaCount: '1',
            verifyReplicaCount: 'true',
            waitTime: '300000')

You should see these logs in Jenkins:

[rollout:latest:deploymentconfig/micro-service] rolled out
[rollout:status:deploymentconfig/micro-service] Waiting for rollout to finish: 0 out of 1 new replicas have been updated...
[rollout:status:deploymentconfig/micro-service] Waiting for rollout to finish: 0 out of 1 new replicas have been updated...
[rollout:status:deploymentconfig/micro-service] Waiting for rollout to finish: 1 old replicas are pending termination...
[rollout:status:deploymentconfig/micro-service] Waiting for rollout to finish: 1 old replicas are pending termination...
[rollout:status:deploymentconfig/micro-service] Waiting for latest deployment config spec to be observed by the controller loop...
[rollout:status:deploymentconfig/micro-service] replication controller "micro-service-12" successfully rolled out


The direct usage of the built Artifact is a much cleaner approach and ensures a tight coupling between artifact and docker image build with Jenkins. Everything is controlled now in the Jenkinsfile, so can you adjust the level of automation and deployment depth yourself.

About the author: Vinh Nguyên

Loves to code, hike and mostly drink black coffee. Favors Apache Kafka, Elasticsearch, Java Development and 80's music.

Join us