Operations 5 min read

Managing Multi‑Platform Build Environments with Jenkins Lockable Resources Plugin

This article explains how to use Jenkins' Lockable Resources Plugin to lock and release virtual machines across Linux, AIX, Windows, Solris, and HP‑UX, ensuring that concurrent jobs do not interfere with each other's environments during development and testing.

DevOps Engineer
DevOps Engineer
DevOps Engineer
Managing Multi‑Platform Build Environments with Jenkins Lockable Resources Plugin

In daily development work, teams often need to switch among many platforms (Linux, AIX, Windows, Solris, HP‑UX) and different software versions, but limited virtual machines make it impossible to provision a dedicated VM for every build and test, leading to long setup times.

The analysis shows that Docker cannot satisfy the requirement because it only supports Linux and Windows, and the Artifactory service is temporarily unavailable, so the only viable solution is to build from source code while managing resource contention through locking.

The article introduces Jenkins' Lockable Resources Plugin as the mechanism to lock a VM when a job starts and release it after completion, preventing other jobs from using the same node simultaneously.

Demo steps include:

Configuring lockable resources in Jenkins global settings.

Viewing the resource pool, which initially shows two free resources.

Running parameterized jobs that select different platforms and repositories, observing how the first job locks a resource, the second job waits, and a third job is blocked until a resource is released.

Releasing a locked resource manually and confirming that the waiting job proceeds successfully.

The core of the solution is a Jenkins pipeline that uses the lock step and an input prompt to hold the lock until a user confirms completion. The full Jenkinsfile is shown below:

pipeline {
    agent {
        node {
            label 'PreDevENV'
        }
    }
    options {
        lock(label: 'PreDevENV', quantity: 1)
    }
    parameters {
        choice(name: 'platform', choices: ['Linux', 'AIX', 'Windows', 'Solris', 'HP-UX'], description: 'Required: which platform do you want to build')
        choice(name: 'repository', choices: ['repo-0.1', 'repo-1.1', 'repo-2.1', 'repo-3.1', 'repo-4.1'], description: 'Required: which repository do you want to build')
        string(name: 'branch', defaultValue: '', description: 'Required: which branch do you want to build')
    }
    stages {
        stage('git clone') {
            steps {
                echo "git clone source"
            }
        }
        stage('start build') {
            steps {
                echo "start build"
            }
        }
        stage('install build') {
            steps {
                echo "installing"
            }
        }
        stage('unlock your resource') {
            steps {
                input message: "do you have finished?"
                echo "Yes, I have finished"
            }
        }
    }
}
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

ci/cdAutomationDevOpsPipelineJenkinsLockable Resources
DevOps Engineer
Written by

DevOps Engineer

DevOps engineer, Pythonista and FOSS contributor. Created cpp-linter, commit-check, etc.; contributed to PyPA.

0 followers
Reader feedback

How this landed with the community

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.