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

A failure in post/always should not prevent the post/failure block to be called

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Hey o/ ,

      If there's an error in some step of the post/always {} block, it seems like this will stop the processing of the post sub-steps.
      I put it Critical, but it almost seems like a blocker: this seems a common use case and counter-intuitive, so I hope you'll agree this is not expected/intended.

      Typical case:

      • I want to always generate some reports (junit, say)
      • I want to notify people *only* on failure

      If something goes wrong in always, still the failure notification should go out for instance.

      Reproduction code:

      pipeline {
          
          agent {
              label 'linux'
          }
          
          post {
              always {
                  echo "ALWAYS THE SUN!!!"
                  junit '**/nonexisting_to_make_this_fail/*.xml'
              }
              failure {
                  echo "WE FAILED MISERABLY! I won't be shown because junit step failed above"
              }
          }
          
          stages {
              stage('bim') {
                  steps {
                      sh "echo bonjour"
                      
                      sh "exit 1"
                  }
              }
          }
      }
      

        Attachments

          Issue Links

            Activity

            Hide
            abayer Andrew Bayer added a comment -

            Interesting question this poses - if post/always fails, but the build was successful up until then, should post/failure be called or post/success?

            Show
            abayer Andrew Bayer added a comment - Interesting question this poses - if post/always fails, but the build was successful up until then, should post/failure be called or post/success?
            Hide
            abayer Andrew Bayer added a comment -

            My bias here is to still follow the previously satisfied conditions, but that's in part 'cos that's how the behavior would work right now. =)

            Show
            abayer Andrew Bayer added a comment - My bias here is to still follow the previously satisfied conditions, but that's in part 'cos that's how the behavior would work right now. =)
            Hide
            abayer Andrew Bayer added a comment -

            Changed my mind! Implementing now.

            Show
            abayer Andrew Bayer added a comment - Changed my mind! Implementing now.
            Hide
            batmat Baptiste Mathus added a comment -

            So, IIUC:

            1. you agree that if the pipeline fails (i.e. before the post/* things), then right now the behaviour is a bug, right?
            2. but in case post/always fails, then there's a question

            I think that, yes, if post/always fails, then it should just trigger whatever post/failure or post/unstable steps are defined. I seem this is the less surprising behaviour.

            Show
            batmat Baptiste Mathus added a comment - So, IIUC: you agree that if the pipeline fails (i.e. before the post/* things), then right now the behaviour is a bug, right? but in case post/always fails, then there's a question I think that, yes, if post/always fails, then it should just trigger whatever post/failure or post/unstable steps are defined. I seem this is the less surprising behaviour.
            Show
            abayer Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/90
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Andrew Bayer
            Path:
            pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/AbstractBuildConditionResponder.groovy
            pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy
            pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Stage.groovy
            pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/model/BuildCondition.java
            pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
            pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/BuildConditionResponderTest.java
            pipeline-model-definition/src/test/resources/postChecksAllConditions.groovy
            http://jenkins-ci.org/commit/pipeline-model-definition-plugin/c1a77937ed5557da7d8796011c13888c05b08c8c
            Log:
            [FIXED JENKINS-40984] Always evaluate/run all post conditions

            Even if there's an error in an earlier condition execution, continue
            to the subsequent ones. Additionally, switch to doing a one-off check
            at the beginning of the post section to see if any conditions are
            satisfied at that time, and then when actually iterating through the
            conditions, check for satisfaction at that time. That's so that, for
            example, if the build is successful when it gets to evaluating post
            conditions and then there's a failure in the execution of `always`,
            the `success` block won't be executed, and the `failure` block will,
            since the build status has changed.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Andrew Bayer Path: pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/AbstractBuildConditionResponder.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Root.groovy pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Stage.groovy pipeline-model-definition/src/main/java/org/jenkinsci/plugins/pipeline/modeldefinition/model/BuildCondition.java pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/BuildConditionResponderTest.java pipeline-model-definition/src/test/resources/postChecksAllConditions.groovy http://jenkins-ci.org/commit/pipeline-model-definition-plugin/c1a77937ed5557da7d8796011c13888c05b08c8c Log: [FIXED JENKINS-40984] Always evaluate/run all post conditions Even if there's an error in an earlier condition execution, continue to the subsequent ones. Additionally, switch to doing a one-off check at the beginning of the post section to see if any conditions are satisfied at that time, and then when actually iterating through the conditions, check for satisfaction at that time. That's so that, for example, if the build is successful when it gets to evaluating post conditions and then there's a failure in the execution of `always`, the `success` block won't be executed, and the `failure` block will, since the build status has changed.
            Hide
            amunro Alastair Munro added a comment - - edited

            I have a similar issue. But its due to someone pressing the abort button more than once; the first abort drops the pipeline from the stage into the post. Then when executing always in post, if the abort button is clicked again, the post always is exited part of the way through. Should I open a new issue?

            Show
            amunro Alastair Munro added a comment - - edited I have a similar issue. But its due to someone pressing the abort button more than once; the first abort drops the pipeline from the stage into the post. Then when executing always in post, if the abort button is clicked again, the post always is exited part of the way through. Should I open a new issue?

              People

              • Assignee:
                abayer Andrew Bayer
                Reporter:
                batmat Baptiste Mathus
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: