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.
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.
DevOps Cloud Academy
Exploring industry DevOps practices and technical expertise.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.