[JENKINS-65290] Locked resource(s) should be inherited from calling job

In a declarative pipeline, I typically do

pipeline {

  options { lock(extra: [[resource: "A"], [resource: "B"], [resource: "C"]]) }

  stages { stage('A') { ... } }

}

or something like that to lock resources for the job.

If I call another build in one of the stages

stage('A') {

  steps {

    script { build job: 'path-to-job' }

  }

}

that build must not try to lock the same resources, because they are already locked by the calling job and hence not available.

Ideally, the plugin would check whether the resources are locked by the calling job, so the called/nested job need not wait for the resources because they are basically already locked for them.

There might be an elaborate (hence "Major") workaround to implement that check manually and it to the jobs that are called by others, but ideally the plugin itself would handle this case.

 

---
Originally reported by raketenolli, imported from: Locked resource(s) should be inherited from calling job

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

Raw content of original issue

In a declarative pipeline, I typically do



pipeline {

  options { lock(extra: [[resource: "A"], [resource: "B"], [resource: "C"]]) }

  stages { stage('A') { ... } }

}





or something like that to lock resources for the job.


If I call another build in one of the stages



stage('A') {

  steps {

    script { build job: 'path-to-job' }

  }

}



that build must not try to lock the same resources, because they are already locked by the calling job and hence not available.


Ideally, the plugin would check whether the resources are locked by the calling job, so the called/nested job need not wait for the resources because they are basically already locked for them.


There might be an elaborate (hence "Major") workaround to implement that check manually and it to the jobs that are called by others, but ideally the plugin itself would handle this case.

  

• environment: Jenkins 2.263.4, lockable-resources-plugin 2.10

Start by examining the lockable-resources-plugin handling of Declarative Pipeline locks and nested build steps invoked with build job. Reproduce the A/B/C resource scenario and determine how a called job can recognize resources held by its caller. Done means nested jobs do not wait for resources already locked by the calling job, with coverage for this behavior.

Written by the indexing model from the issue text.