Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-65290

Locked resource(s) should be inherited from calling job

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins 2.263.4, lockable-resources-plugin 2.10
    • Similar Issues:

      Description

      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.
       

        Attachments

          Activity

          raketenolli Oliver created issue -
          raketenolli Oliver made changes -
          Field Original Value New Value
          Description In a declarative pipeline, I typically do

          {{pipeline {}}
          {{  options { l{color:#000000}ock(extra: [[resource: {color}{color:#a31515}"A{color}{color:#a31515}"{color}{color:#000000}], [resource: {color}{color:#a31515}"B{color}{color:#a31515}"{color}{color:#000000}], [resource: "C"]]) {color}{color:#000000}}
          {color}{color:#000000}  stages \{ stage('A') { ... } }
          {color}{color:#000000}}{color}}}

          {color:#000000}or something like that to lock resources for the job.{color}

          {color:#000000}If I call another build in one of the stages {color}

          {{{color:#000000}stage('A') {
          {color}{color:#000000}  steps {
          {color}{color:#000000}    script \{ build job: 'path-to-job' }
          {color}{color:#000000}  }
          {color}{color:#000000}}{color}}}

          {color:#000000}that build must not try to lock the same resources, because they are already locked by the calling job and hence not available.{color}

          {color:#000000}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.{color}

          {color:#000000}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.{color}
           
          In a declarative pipeline, I typically do

          {{pipeline {}}
           {{  options { l{color:#000000}ock(extra: [[resource: {color}{color:#a31515}"A{color}{color:#a31515}"{color}{color:#000000}], [resource: {color}{color:#a31515}"B{color}{color:#a31515}"{color}{color:#000000}], [resource: "C"]]) }{color}}}
             stages \{ stage('A') { ... } }
          }
           
           or something like that to lock resources for the job.

          {color:#000000}If I call another build in one of the stages {color}

          {{{color:#000000}stage('A') {{color}{color:#000000}  steps {{color}{color:#000000}    script \{ build job: 'path-to-job' }{color}{color:#000000}  }{color}{color:#000000}}}}
           
           that build must not try to lock the same resources, because they are already locked by the calling job and hence not available.

          {color:#000000}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.{color}

          {color:#000000}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.{color}
            
          raketenolli Oliver made changes -
          Description In a declarative pipeline, I typically do

          {{pipeline {}}
           {{  options { l{color:#000000}ock(extra: [[resource: {color}{color:#a31515}"A{color}{color:#a31515}"{color}{color:#000000}], [resource: {color}{color:#a31515}"B{color}{color:#a31515}"{color}{color:#000000}], [resource: "C"]]) }{color}}}
             stages \{ stage('A') { ... } }
          }
           
           or something like that to lock resources for the job.

          {color:#000000}If I call another build in one of the stages {color}

          {{{color:#000000}stage('A') {{color}{color:#000000}  steps {{color}{color:#000000}    script \{ build job: 'path-to-job' }{color}{color:#000000}  }{color}{color:#000000}}}}
           
           that build must not try to lock the same resources, because they are already locked by the calling job and hence not available.

          {color:#000000}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.{color}

          {color:#000000}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.{color}
            
          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.

          {color:#000000}If I call another build in one of the stages {color}

          {{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.

          {color:#000000}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.{color}

          {color:#000000}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.{color}
            
          raketenolli Oliver made changes -
          Description 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.

          {color:#000000}If I call another build in one of the stages {color}

          {{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.

          {color:#000000}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.{color}

          {color:#000000}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.{color}
            
          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.

          {color:#000000}If I call another build in one of the stages {color}

          {{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.

          {color:#000000}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.{color}

          {color:#000000}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.{color}
            
          raketenolli Oliver made changes -
          Description 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.

          {color:#000000}If I call another build in one of the stages {color}

          {{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.

          {color:#000000}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.{color}

          {color:#000000}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.{color}
            
          In a declarative pipeline, I typically do
          {code:java}
          pipeline {
            options { lock(extra: [[resource: "A"], [resource: "B"], [resource: "C"]]) }
            stages { stage('A') { ... } }
          }
          {code}
          or something like that to lock resources for the job.

          If I call another build in one of the stages
          {code:java}
          stage('A') {
            steps {
              script { build job: 'path-to-job' }
            }
          }{code}
          {color:#000000}{color}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.
            
          tgr Tobias Gruetzmacher made changes -
          Assignee Tobias Gruetzmacher [ tgr ]

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            raketenolli Oliver
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Dates

              Created:
              Updated: