Operations 6 min read

Deploying a Container Build Resource Pool and Optimizing Jenkins Shared Library for CI/CD

This article shares a DevOps engineer's practical experience of deploying a container‑based build resource pool on OpenShift, managing an artifact repository, and optimizing Jenkins shared libraries with parameterized pipelines to improve CI/CD efficiency and reliability.

DevOps Cloud Academy
DevOps Cloud Academy
DevOps Cloud Academy
Deploying a Container Build Resource Pool and Optimizing Jenkins Shared Library for CI/CD

The author, a DevOps engineer with 4‑5 years of experience, introduces a weekly technical summary covering three main topics: container build resource pool deployment, artifact repository trial run, and Jenkins shared library optimization.

1. Container Build Resource Pool Deployment – The build platform runs on VMs with one master and multiple slaves. Growing project count caused disk space and executor shortages. The solution separates build and release onto different nodes, fixes slaves in containers, and creates a generic Jenkins slave image containing Maven, Ant, Gradle, JDK, and agent.jar . The image is deployed on OpenShift with labeled nodes, a service account with root privileges, persistent PV/PVC for cache, and a DeploymentConfig with replica count set to 1.

Jenkins master is then configured to connect to these containerized slaves via fixed labels, avoiding the long wait times of dynamic K8s plugin provisioning.

2. Artifact Repository Trial Run – The pipeline previously deleted build artifacts after deployment, preventing version traceability and rollback. Issues identified include duplicate builds and lack of code‑artifact linkage. The proposed fixes define a versioning scheme, add quality gates before uploading, and associate code tags with artifact versions using the Artifactory plugin and GitLab API.

3. Jenkins Shared Library Optimization – The author demonstrates a parameterized pipeline that selects different workflows (CI, CD, CICD, GitCommit) based on a runModes variable. The shared library structure includes src/xxx/xxx/xxx.groovy and several vars/*.groovy files (ciPipeline.groovy, cdPipeline.groovy, ciCdPipeline.groovy, gitCommitPipeline.groovy). A concise Jenkinsfile delegates to the appropriate library function:

#!groovy
@Library("Jlibrary@master") _
String runModes = "${env.runModes}"
switch ("${runModes}") {
    case "CI":
        ciPipeline()
    case "CD":
        cdPipeline()
    case "CICD":
        ciCdPipeline()
    case "GitCommit":
        gitCommitPipeline()
    default:
        defaultPipeline()
}

The article concludes with reflections on implementation pitfalls, such as handling JSON in Jenkinsfiles (solved with the readJSON plugin), and encourages readers to share the content and reach out via the public account for further discussion.

ci/cdDevOpsContainerShared LibraryJenkinsartifact repositoryOpenShift
DevOps Cloud Academy
Written by

DevOps Cloud Academy

Exploring industry DevOps practices and technical expertise.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.