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

Stage locks are created for skipped stages in declarative pipeline

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Given the following declarative pipeline:

      pipeline {
        stages {
          stage('Example stage') {
            when { expression { false } }
            options { lock resource: 'example resource' }
            steps { // ... }
          }
        }
      }
      

      Even though 'example stage' is skipped due to the when conditional, a lockable resource 'example resource' is created (if it doesn't already exist) and a lock is acquired on it. I think this is counter intuitive. The consequence is also really bad – a skipped stage might actually make the whole build hang (possibly for a long time) because it needs to acquire a lock on a busy resource (typically used by another build).

        Attachments

          Issue Links

            Activity

            Hide
            famod Falko Modler added a comment -

            Stephen Connolly thanks for sharing your workaround.

            Unfortunately this won't work in case the criteria to check of is calculcated in a previous stage, e.g.:

            pipeline {
              stages {
                stage('Calculate criteria') {
                  steps {
                    script {
                      someCriteria = true
                    }
                  }
                }
                stage('Example stage') {
                  when {
                    expression {
                      return someCriteria
                    }
                  }
                  options { lock resource: "${someCriteria ? 'example resource':'dummy'}" }
                  steps { // ... }
                }
              }
            }
            

            This will fail in options with:

            groovy.lang.MissingPropertyException: No such property: someCriteria for class: groovy.lang.Binding
            Show
            famod Falko Modler added a comment - Stephen Connolly thanks for sharing your workaround. Unfortunately this won't work in case the criteria to check of is calculcated in a previous stage, e.g.: pipeline { stages { stage( 'Calculate criteria' ) { steps { script { someCriteria = true } } } stage( 'Example stage' ) { when { expression { return someCriteria } } options { lock resource: "${someCriteria ? 'example resource' : 'dummy' }" } steps { // ... } } } } This will fail in options with: groovy.lang.MissingPropertyException: No such property: someCriteria for class: groovy.lang.Binding
            Hide
            wgc123 D Pasto added a comment -

            It also doesn’t work because either you hardcore “dummy” and potentially block on it or you randomize and create all sorts of crap in your Jenkins config

            Show
            wgc123 D Pasto added a comment - It also doesn’t work because either you hardcore “dummy” and potentially block on it or you randomize and create all sorts of crap in your Jenkins config
            Hide
            famod Falko Modler added a comment - - edited

            D Pasto

            It also doesn’t work because either you hardcore “dummy” and potentially block on it

            Those potential blocks/locks are very short-lived. You could also define a pool of multiple "dummy" resources to further reduce the (already very small) impact.

            So this partial workaround is better than nothing.

            Andrew Bayer

            You can always put lock or timeout (and any other block-scoped options) in your steps instead.

            Unfortunately, this is no solution/workaround for post blocks. E.g. you lock some external resource/server and in post you want to collect the server's logfiles (regardless of the build status).
            So IMHO, beforeOptions is still needed.

            Show
            famod Falko Modler added a comment - - edited D Pasto It also doesn’t work because either you hardcore “dummy” and potentially block on it Those potential blocks/locks are very short-lived. You could also define a pool of multiple "dummy" resources to further reduce the (already very small) impact. So this partial workaround is better than nothing. Andrew Bayer You can always put lock or timeout (and any other block-scoped options) in your steps instead. Unfortunately, this is no solution/workaround for post blocks. E.g. you lock some external resource/server and in post you want to collect the server's logfiles (regardless of the build status). So IMHO, beforeOptions is still needed.
            Show
            famod Falko Modler added a comment - I created a PR for this: https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/356
            Hide
            famod Falko Modler added a comment - - edited

            Liam Newman I have just resolved this ticket because the fix is included in 1.4.0. I am not familiar with the overall ticket workflow, though.
            So I leave it up to you (or Andrew Bayer) to close this issue.

            Show
            famod Falko Modler added a comment - - edited Liam Newman I have just resolved this ticket because the fix is included in 1.4.0. I am not familiar with the overall ticket workflow, though. So I leave it up to you (or Andrew Bayer ) to close this issue.

              People

              Assignee:
              famod Falko Modler
              Reporter:
              thxmasj Thomas Johansen
              Votes:
              5 Vote for this issue
              Watchers:
              11 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: