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

    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

            batmat Baptiste Mathus created issue -
            abayer Andrew Bayer made changes -
            Field Original Value New Value
            Status Open [ 1 ] In Progress [ 3 ]
            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?

            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?
            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. =)

            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. =)
            abayer Andrew Bayer added a comment -

            Changed my mind! Implementing now.

            abayer Andrew Bayer added a comment - Changed my mind! Implementing now.

            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.

            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.
            abayer Andrew Bayer made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            abayer Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/90
            abayer Andrew Bayer made changes -
            Remote Link This issue links to "PR #90 (Web Link)" [ 15246 ]
            abayer Andrew Bayer made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]

            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.

            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.
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal OSS-1833 (Web Link)" [ 18545 ]
            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?

            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?
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.
            bitwiseman Liam Newman made changes -
            Status Resolved [ 5 ] Closed [ 6 ]

            People

              abayer Andrew Bayer
              batmat Baptiste Mathus
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: