[JENKINS-61502] Option to (abort,mark unstable, queue) if resouce(s) are unavailable.

If job cannot lock resources, provide finer control, instead of just queuing. 

options{

 lock( ifLocked:'abort' ,extra:[[resource:'resource1'],[resource:'resource2']])

}

 

With timeout field  ? JENKINS-41699">JENKINS-41699

options{ 

  lock( timeout: 4, onTimeout:'abort' ,extra:[[resource:'resource1'],[resource:'resource2']])

 }

 

This pipeline demonstrates the desired effect, but is unusable inside the sandbox.

/*

First build acquires one of two locks. Second build acquires the second lock, but the resource check step aborts the job if all locks are used up. Additional builds will queue and eventually fall into one of the first two scenarios */


//envLock = [envResource1, envResource2]

//workspaceLock = [wsResource1, wsResouece2]



import org.jenkins.plugins.lockableresources.LockableResourcesManager as LockMan 

def envLock        = 'envLock'  

def workspaceLock  = 'workSpaceLock'

pipeline{

  options {

     lock(extra: [[label:envLock, quantity: 1], [label:workspaceLock, quantity: 1]])

  }

  stages {

     stage('Resource Availability Check'){

       when { expression  { LockMan.get().getFreeResourceAmount(envLock) == 0 || LockMan.get().getFreeResourceAmount(workspaceLock) == 0 } }

       steps{

 script{

   currentBuild.result = 'ABORTED'

   error('Some other Pipeline is already using the resources, please try again later.')

 }

       }

     }

    stage('Install/Update Tools'){

      steps{

echo ("./gradlew install")

    }}

}}

 

---
Originally reported by truesoupfly, imported from: Option to (abort,mark unstable, queue) if resouce(s) are unavailable.

• status: Open
  
• priority: Minor
  
• component(s): lockable-resources-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 1
  
• imported: 20251217-081411
  

Raw content of original issue

If job cannot lock resources, provide finer control, instead of just queuing. 



options{

 lock( ifLocked:'abort' ,extra:[[resource:'resource1'],[resource:'resource2']])

}



 


With timeout field  ? JENKINS-41699



options{ 

  lock( timeout: 4, onTimeout:'abort' ,extra:[[resource:'resource1'],[resource:'resource2']])

 }



 


This pipeline demonstrates the desired effect, but is unusable inside the sandbox.



/*

First build acquires one of two locks. Second build acquires the second lock, but the resource check step aborts the job if all locks are used up. Additional builds will queue and eventually fall into one of the first two scenarios */


//envLock = [envResource1, envResource2]

//workspaceLock = [wsResource1, wsResouece2]



import org.jenkins.plugins.lockableresources.LockableResourcesManager as LockMan 

def envLock        = 'envLock'  

def workspaceLock  = 'workSpaceLock'

pipeline{

  options {

     lock(extra: [[label:envLock, quantity: 1], [label:workspaceLock, quantity: 1]])

  }

  stages {

     stage('Resource Availability Check'){

       when { expression  { LockMan.get().getFreeResourceAmount(envLock) == 0 || LockMan.get().getFreeResourceAmount(workspaceLock) == 0 } }

       steps{

         script{

           currentBuild.result = 'ABORTED'

           error('Some other Pipeline is already using the resources, please try again later.')

         }

       }

     }

    stage('Install/Update Tools'){

      steps{

        echo ("./gradlew install")

    }}

}}



 

Start with the Pipeline lock(...) option and the LockableResourcesManager.get().getFreeResourceAmount entry point shown in the issue. Read the referenced JENKINS-41699 timeout request and investigate the sandbox limitation. Done means defining and validating supported behavior for aborting, marking unstable, or queuing when resources are unavailable.

Written by the indexing model from the issue text.