I'd like to create two stages, where if one runs the other doesn't - effectively and `if-else`.

      Right now I'd have to do something like this:

      stages {
          stage ('Full Build') {
              when {
                  expression { return params.FORCE_FULL_BUILD }
              }
          }
      
          stage ('Incremental Build') {
              when {
                  expression { return !params.FORCE_FULL_BUILD }
              }
          }
      }
      

      For simple expressions, that's no problem. For complex expressions it gets tiresome.

      The `when {}` block needs a way to indicate `else`. This could be done (when combined with a logical `not` condition) by have a `stage` condition. Like so:

      stages {
          stage ('Full Build') {
              when {
                  expression { return params.FORCE_FULL_BUILD }
              }
          }
      
          stage ('Incremental Build') {
              when {
                  not { stage 'Full Build' }
              }
          }
      }
      

      This would also allow for stages to depend on previous stages in a clear fashion. For example:

      stages {
          stage ('Full Build') {
              when {
                  expression { return params.FORCE_FULL_BUILD }
              }
          }
      
          stage ('Incremental Build') {
              when {
                  not { stage 'Full Build' }
              }
          }
      
          stage ('Full Tests') {
              when {
                  stage 'Full Build' }
              }
          }
      
          stage ('Incremental Tests') {
              when {
                  stage 'Incremental Build' }
              }
          }
      }
      

          [JENKINS-41187] Stage "when" should have "stage" condition

          Liam Newman created issue -
          Liam Newman made changes -
          Link New: This issue relates to JENKINS-41185 [ JENKINS-41185 ]

          Patrick Wolf added a comment - - edited

          I don't like this syntax formatting.

          When I see this :

          stage ('Incremental Build') {
                  when {
                      not { stage 'Full Build' }
                  }
              }
          

          I read it as when this Stage is not "Full Build". My first reaction is that is always true.

          If we want to say it is dependent in someway then we need to make that relationship explicit. When stage "Full Build" is not what? Not skipped, not run, not stable? That isn't clear.

          Right now the use case described is easily done as shown. To me that is much more clear than the alternative. We can explore having some stage conditions but they need to be clear.

          Maybe something like:

          stage ('Incremental Build') {
                  when {
                       stage 'Full Build'  == SKIPPED
                  }
              }
          

          Or

          stage ('Incremental Build') {
                  when {
                       stage 'Full Build'  == SUCCESS
                  }
              }
          

          Or

          stage ('Incremental Build') {
                  when {
                       stage 'Full Build'  != UNSTABLE
                  }
              }
          

          Patrick Wolf added a comment - - edited I don't like this syntax formatting. When I see this : stage ( 'Incremental Build' ) { when { not { stage 'Full Build' } } } I read it as when this Stage is not "Full Build". My first reaction is that is always true. If we want to say it is dependent in someway then we need to make that relationship explicit. When stage "Full Build" is not what? Not skipped, not run, not stable? That isn't clear. Right now the use case described is easily done as shown. To me that is much more clear than the alternative. We can explore having some stage conditions but they need to be clear. Maybe something like: stage ( 'Incremental Build' ) { when { stage 'Full Build' == SKIPPED } } Or stage ( 'Incremental Build' ) { when { stage 'Full Build' == SUCCESS } } Or stage ( 'Incremental Build' ) { when { stage 'Full Build' != UNSTABLE } }

          Liam Newman added a comment -

          hrmpw
          I'm open to discussion of how it should look, but I think we need some form of this.

          "Right now the use case described is easily done as shown."
          Yes, like I said, for simple expressions things are fine, but for complex expressions this would get unwieldy very fast.

          stages {
              stage ('Full Build') {
                  when {
                      expression {
                          GIT_BRANCH = 'origin/' + sh(returnStdout: true, script: 'git rev-parse --abbrev-ref HEAD').trim()
                          return GIT_BRANCH == 'origin/master' || params.FORCE_FULL_BUILD
                      }
                  }
              }
          
              stage ('Incremental Build') {
                  when {
                      expression {
                          GIT_BRANCH = 'origin/' + sh(returnStdout: true, script: 'git rev-parse --abbrev-ref HEAD').trim()
                          return !(GIT_BRANCH == 'origin/master' || params.FORCE_FULL_BUILD)
                      }
                  }
              }
          }
          

          Then repeat that condition over and over for other stages. Mediocre.

          I see your point about the specific `stage {}` condition syntax I described being not great, but I also don't want to use general comparison operators if we can avoid them here. Also, stages run in serial and failure in a previous stage would generally stop the pipeline right?

          Maybe this:

          stages {
              stage ('Full Build') {
                  when {
                      expression { return params.FORCE_FULL_BUILD }
                  }
              }
          
              stage ('Incremental Build') {
                  when {
                      stages('Full Build').skipped
                  }
              }
          
              stage ('Full Tests') {
                  when {
                      stages('Full Build').executed
                  }
              }
          
              stage ('Incremental Tests') {
                  when {
                      stages('Incremental Build').executed
                  }
              }
          }
          

          Or we could follow your status example:

          stages {
              stage ('Full Build') {
                  when {
                      expression { return params.FORCE_FULL_BUILD }
                  }
              }
          
              stage ('Incremental Build') {
                  when {
                      stages('Full Build').skipped
                  }
              }
          
              stage ('Full Tests') {
                  when {
                      stages('Full Build').succeeded 
                  }
              }
          
              stage ('Incremental Tests') {
                  when {
                      stages('Incremental Build').succeeded
                  }
              }
          }
          

          Liam Newman added a comment - hrmpw I'm open to discussion of how it should look, but I think we need some form of this. "Right now the use case described is easily done as shown." Yes, like I said, for simple expressions things are fine, but for complex expressions this would get unwieldy very fast. stages { stage ( 'Full Build' ) { when { expression { GIT_BRANCH = 'origin/' + sh(returnStdout: true , script: 'git rev-parse --abbrev-ref HEAD' ).trim() return GIT_BRANCH == 'origin/master' || params.FORCE_FULL_BUILD } } } stage ( 'Incremental Build' ) { when { expression { GIT_BRANCH = 'origin/' + sh(returnStdout: true , script: 'git rev-parse --abbrev-ref HEAD' ).trim() return !(GIT_BRANCH == 'origin/master' || params.FORCE_FULL_BUILD) } } } } Then repeat that condition over and over for other stages. Mediocre. I see your point about the specific `stage {}` condition syntax I described being not great, but I also don't want to use general comparison operators if we can avoid them here. Also, stages run in serial and failure in a previous stage would generally stop the pipeline right? Maybe this: stages { stage ( 'Full Build' ) { when { expression { return params.FORCE_FULL_BUILD } } } stage ( 'Incremental Build' ) { when { stages( 'Full Build' ).skipped } } stage ( 'Full Tests' ) { when { stages( 'Full Build' ).executed } } stage ( 'Incremental Tests' ) { when { stages( 'Incremental Build' ).executed } } } Or we could follow your status example: stages { stage ( 'Full Build' ) { when { expression { return params.FORCE_FULL_BUILD } } } stage ( 'Incremental Build' ) { when { stages( 'Full Build' ).skipped } } stage ( 'Full Tests' ) { when { stages( 'Full Build' ).succeeded } } stage ( 'Incremental Tests' ) { when { stages( 'Incremental Build' ).succeeded } } }
          James Dumay made changes -
          Summary Original: [Declarative Pipeline] Stage "when" should have "stage" condition New: Stage "when" should have "stage" condition
          James Dumay made changes -
          Epic Link New: JENKINS-45426 [ 183594 ]

          Joe Cavanaugh added a comment -

          I agree with this wholeheartedly. Has this gotten any traction lately? 

          Joe Cavanaugh added a comment - I agree with this wholeheartedly. Has this gotten any traction lately? 
          Andrew Bayer made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          Andrew Bayer added a comment -

          Andrew Bayer added a comment - I'm implementing this in a new plugin - https://github.com/abayer/declarative-pipeline-when-conditions-plugin .
          Andrew Bayer made changes -
          Remote Link New: This issue links to "new plugin repo (initial) (Web Link)" [ 17831 ]

            Unassigned Unassigned
            bitwiseman Liam Newman
            Votes:
            11 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated: