It'd be handy to be able to have notifications specified for individual stages as well as for the whole build.

          [JENKINS-37792] Pipeline Config: Notifications per stage

          Andrew Bayer created issue -
          Andrew Bayer made changes -
          Assignee Original: Andrew Bayer [ abayer ] New: rsandell [ rsandell ]

          Andrew Bayer added a comment -

          Might actually be better to call this postBuild rather than notifications - the core distinction between postBuild and notifications is that postBuild runs within the node block the build executed in, which would be the case for any post-stage action (though with per-stage agents, we'd have to explicitly put this execution inside that, but that's trivial enough)...

          Andrew Bayer added a comment - Might actually be better to call this postBuild rather than notifications - the core distinction between postBuild and notifications is that postBuild runs within the node block the build executed in, which would be the case for any post-stage action (though with per-stage agents, we'd have to explicitly put this execution inside that, but that's trivial enough)...

          When I think about this, I feel that the requirement can probably be satisfied by changing how we structure things.

          If the stage (or notifications) block contains node configuration and then an ordered sequence of conditions (where steps is just sort of an alias for success)

          Thus we can have

          pipeline {
          
            agent label:'nix'
          
            stages {
              stage('unix') {
                steps {
                  ...
                }
                success {
                  ...
                }
                steps {
                  ...
                }
                always {
                  ...
                }
              }
              stage('windows') {
                agent label:'win'
                steps {
                  ...
                }
                success {
                  ...
                }
                failure {
                  ...
                }
              }
            }
            notifications {
              // by default these get no node, but we can specify a config here to get a node for them
              agent label:'irc-server'
              always {
                ...
              }
            }
          }
          

          Stephen Connolly added a comment - When I think about this, I feel that the requirement can probably be satisfied by changing how we structure things. If the stage (or notifications) block contains node configuration and then an ordered sequence of conditions (where steps is just sort of an alias for success ) Thus we can have pipeline { agent label:'nix' stages { stage('unix') { steps { ... } success { ... } steps { ... } always { ... } } stage('windows') { agent label:'win' steps { ... } success { ... } failure { ... } } } notifications { // by default these get no node, but we can specify a config here to get a node for them agent label:'irc-server' always { ... } } }

          Andrew Bayer added a comment -

          Beyond the messiness of all of those success/failure/etc blocks in the stage block (I admit it, my Lisp background makes me perceive arbitrarily deep nested maps as the natural state of the world), we'd still need a way to signify "run this block of steps after the main block of steps for this stage has completed, regardless of the status of the build at that point" - i.e., for "always run this cleanup script" kind of stuff. Since the "steps" contents aren't guaranteed to all be executed (i.e., if the first one is error 'foo', we'll never actually get to subsequent steps, nor should we!) we can't rely on steps to take the place of always.

          And again, I don't like the UX of putting steps, success, failure et al at the same level. It's cluttered and confusing.

          hrmpw, michaelneale, thoughts?

          Andrew Bayer added a comment - Beyond the messiness of all of those success/failure/etc blocks in the stage block (I admit it, my Lisp background makes me perceive arbitrarily deep nested maps as the natural state of the world), we'd still need a way to signify "run this block of steps after the main block of steps for this stage has completed, regardless of the status of the build at that point" - i.e., for "always run this cleanup script" kind of stuff. Since the "steps" contents aren't guaranteed to all be executed (i.e., if the first one is error 'foo' , we'll never actually get to subsequent steps, nor should we!) we can't rely on steps to take the place of always . And again, I don't like the UX of putting steps , success , failure et al at the same level. It's cluttered and confusing. hrmpw , michaelneale , thoughts?

          abayer each stage is then basically a processing of the list of conditions... (steps being a sort of special condition that is "run this if all the previous steps in this stage completed successfully" which is subtly different from success. all the conditions in a stage would always be evaluated and their contents executed until one of the content steps fails or all content steps are executed.

          Stephen Connolly added a comment - abayer each stage is then basically a processing of the list of conditions... ( steps being a sort of special condition that is "run this if all the previous steps in this stage completed successfully" which is subtly different from success . all the conditions in a stage would always be evaluated and their contents executed until one of the content steps fails or all content steps are executed.

          Patrick Wolf added a comment -

          Having notifications and postBuild blocks outside of stages but only a postBuild block within the stage is too inconsistent for me. I think the terms should be the same.

          I'm not sure why success and steps would be aliased, they seem to have different functions, but I somewhat like stephenconnolly suggestion. I'm not sure about multiple steps blocks. We could even use this format instead of an explicit postBuild block if we put success, failure, always within the stages block outside of the stages:

          stages {
              stage('unix') {
                steps {
                  ...
                }
                success {
                  ...
                }
                always {
                  ...
                }
              }
              stage('windows') {
                agent label:'win'
                steps {
                  ...
                }
                success {
                  ...
                }
                failure {
                  ...
                }
              }
            success{
             ...
            }
            failure{
              ...
            }
            }
          

          If we are going to combine postBuild and notifications for stages I think we should do the same overall.

          Patrick Wolf added a comment - Having notifications and postBuild blocks outside of stages but only a postBuild block within the stage is too inconsistent for me. I think the terms should be the same. I'm not sure why success and steps would be aliased, they seem to have different functions, but I somewhat like stephenconnolly suggestion. I'm not sure about multiple steps blocks. We could even use this format instead of an explicit postBuild block if we put success , failure , always within the stages block outside of the stages: stages { stage( 'unix' ) { steps { ... } success { ... } always { ... } } stage( 'windows' ) { agent label: 'win' steps { ... } success { ... } failure { ... } } success{ ... } failure{ ... } } If we are going to combine postBuild and notifications for stages I think we should do the same overall.

          hrmpw my proposal is that we kill off postBuild there is no postBuild any more.

          I would be against having conditionals in the raw stages... if you still see the need for that it would, to my mind, be a finally or lastly

          stages {
              stage('unix') {
                steps {
                  ...
                }
                success {
                  ...
                }
                always {
                  ...
                }
              }
              stage('windows') {
                agent label:'win'
                steps {
                  ...
                }
                success {
                  ...
                }
                failure {
                  ...
                }
              }
              lastly {
                success{
                  ...
                }
                failure{
                  ...
                }
              }
            }
          

          the notifications still stays as they are always executed without a node

          Stephen Connolly added a comment - hrmpw my proposal is that we kill off postBuild there is no postBuild any more. I would be against having conditionals in the raw stages... if you still see the need for that it would, to my mind, be a finally or lastly stages { stage( 'unix' ) { steps { ... } success { ... } always { ... } } stage( 'windows' ) { agent label: 'win' steps { ... } success { ... } failure { ... } } lastly { success{ ... } failure{ ... } } } the notifications still stays as they are always executed without a node

          FTR I view postBuild as a terrible name...

          1. it is the only camelCase name in the "keywords" of p-m-d
          2. it is singular compared with notifications and stages which are the comparable containers

          Stephen Connolly added a comment - FTR I view postBuild as a terrible name... 1. it is the only camelCase name in the "keywords" of p-m-d 2. it is singular compared with notifications and stages which are the comparable containers

          Andrew Bayer added a comment -

          fwiw, the name is 'cos we needed it to be all-one-word, not-starting-with-a-capital-letter, so I shrugged and went with postBuild. =)

          Andrew Bayer added a comment - fwiw, the name is 'cos we needed it to be all-one-word, not-starting-with-a-capital-letter, so I shrugged and went with postBuild . =)

            rsandell rsandell
            abayer Andrew Bayer
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: