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

Declarative Pipeline shows SUCCESS even though job FAILED

    Details

    • Similar Issues:
    • Released As:
      pipeline-model-definition 1.3.7

      Description

      Pipelines are "failing" with SUCCESS status. 

      This pipeline, taken from JENKINS-46325 illustrates this issue successfully:

      pipeline {
          agent any
          stages {
              stage ('Init') {
                  steps {
                      echo "Init result: ${currentBuild.result}"
                      echo "Init currentResult: ${currentBuild.currentResult}"
                  }
                  post {
                      always {
                          echo "Post-Init result: ${currentBuild.result}"
                          echo "Post-Init currentResult: ${currentBuild.currentResult}"
                      }
                  }
              }
              stage ('Build') {
                  steps {
                      echo "During Build result: ${currentBuild.result}"
                      echo "During Build currentResult: ${currentBuild.currentResult}"
                      sh 'exit 1'
                  }
                  post {
                      always {
                          echo "Post-Build result: ${currentBuild.result}"
                          echo "Post-Build currentResult: ${currentBuild.currentResult}"
                      }
                  }
              }
          }
          post {
              always {
                  echo "Pipeline result: ${currentBuild.result}"
                  echo "Pipeline currentResult: ${currentBuild.currentResult}"
              }
          }
      }
      

       

      My results are (trimmed down):

      Running on build-096575a3-e6af-4fff-9ca1-84cc46ba4b86-f9b8d29c in /var/vcap/data/jenkins-slave/workspace/test-job
      Init result: null
      Init currentResult: SUCCESS
      Post stage
      Post-Init result: null
      Post-Init currentResult: SUCCESS
      During Build result: null
      During Build currentResult: SUCCESS
      [Pipeline] sh
      + exit 1
      Post stage
      Post-Build result: null
      Post-Build currentResult: SUCCESS
      Pipeline result: null
      Pipeline currentResult: SUCCESS
      ERROR: script returned exit code 1
      Finished: FAILURE
      

       

        Attachments

          Issue Links

            Activity

            pzozobrado Philip Zozobrado created issue -
            pzozobrado Philip Zozobrado made changes -
            Field Original Value New Value
            Description Pipelines are "failing" with SUCCESS status. 

            This pipeline, taken from JENKINS-46325 illustrates this issues successfully:
            {code}
            pipeline {
                agent any
                stages {
                    stage ('Init') {
                        steps {
                            echo "Init result: ${currentBuild.result}"
                            echo "Init currentResult: ${currentBuild.currentResult}"
                        }
                        post {
                            always {
                                echo "Post-Init result: ${currentBuild.result}"
                                echo "Post-Init currentResult: ${currentBuild.currentResult}"
                            }
                        }
                    }
                    stage ('Build') {
                        steps {
                            echo "During Build result: ${currentBuild.result}"
                            echo "During Build currentResult: ${currentBuild.currentResult}"
                            sh 'exit 1'
                        }
                        post {
                            always {
                                echo "Post-Build result: ${currentBuild.result}"
                                echo "Post-Build currentResult: ${currentBuild.currentResult}"
                            }
                        }
                    }
                }
                post {
                    always {
                        echo "Pipeline result: ${currentBuild.result}"
                        echo "Pipeline currentResult: ${currentBuild.currentResult}"
                    }
                }
            }
            {code}
             

            My results are (trimmed down):
            {noformat}
            Running on build-096575a3-e6af-4fff-9ca1-84cc46ba4b86-f9b8d29c in /var/vcap/data/jenkins-slave/workspace/test-job
            Init result: null
            Init currentResult: SUCCESS
            Post stage
            Post-Init result: null
            Post-Init currentResult: SUCCESS
            During Build result: null
            During Build currentResult: SUCCESS
            [Pipeline] sh
            + exit 1
            Post stage
            Post-Build result: null
            Post-Build currentResult: SUCCESS
            Pipeline result: null
            Pipeline currentResult: SUCCESS
            ERROR: script returned exit code 1
            Finished: FAILURE
            {noformat}
             
            Pipelines are "failing" with SUCCESS status. 

            This pipeline, taken from JENKINS-46325 illustrates this issue successfully:
            {code:java}
            pipeline {
                agent any
                stages {
                    stage ('Init') {
                        steps {
                            echo "Init result: ${currentBuild.result}"
                            echo "Init currentResult: ${currentBuild.currentResult}"
                        }
                        post {
                            always {
                                echo "Post-Init result: ${currentBuild.result}"
                                echo "Post-Init currentResult: ${currentBuild.currentResult}"
                            }
                        }
                    }
                    stage ('Build') {
                        steps {
                            echo "During Build result: ${currentBuild.result}"
                            echo "During Build currentResult: ${currentBuild.currentResult}"
                            sh 'exit 1'
                        }
                        post {
                            always {
                                echo "Post-Build result: ${currentBuild.result}"
                                echo "Post-Build currentResult: ${currentBuild.currentResult}"
                            }
                        }
                    }
                }
                post {
                    always {
                        echo "Pipeline result: ${currentBuild.result}"
                        echo "Pipeline currentResult: ${currentBuild.currentResult}"
                    }
                }
            }
            {code}
             

            My results are (trimmed down):
            {noformat}
            Running on build-096575a3-e6af-4fff-9ca1-84cc46ba4b86-f9b8d29c in /var/vcap/data/jenkins-slave/workspace/test-job
            Init result: null
            Init currentResult: SUCCESS
            Post stage
            Post-Init result: null
            Post-Init currentResult: SUCCESS
            During Build result: null
            During Build currentResult: SUCCESS
            [Pipeline] sh
            + exit 1
            Post stage
            Post-Build result: null
            Post-Build currentResult: SUCCESS
            Pipeline result: null
            Pipeline currentResult: SUCCESS
            ERROR: script returned exit code 1
            Finished: FAILURE
            {noformat}
             
            Hide
            kapoorlakshya Lakshya Kapoor added a comment - - edited

            I'm experiencing the same. currentBuild.currentResult for all failed and aborted builds returns "SUCCESS". Same when using $BUILD_STATUS through the emailext plugin.

            Using Jenkins version 2.150.3 and Pipeline 2.6. All pipeline related plugins are at the latest version as well.

            Show
            kapoorlakshya Lakshya Kapoor added a comment - - edited I'm experiencing the same. currentBuild.currentResult  for all failed and aborted builds returns "SUCCESS". Same when using $BUILD_STATUS through the emailext plugin. Using Jenkins version 2.150.3 and Pipeline 2.6. All pipeline related plugins are at the latest version as well.
            pzozobrado Philip Zozobrado made changes -
            Environment Jenkins 2.150.3, using a slave build executioner Jenkins 2.150.3, Pipeline 2.6, using a slave build executioner
            Hide
            kapoorlakshya Lakshya Kapoor added a comment -

            I investigated this issue and looks like it introduced by the Pipeline: Declarative plugin v1.3.5. The offending commit seems to be https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a.

            Downgrading to v1.3.4.1 is the workaround for now.

            Show
            kapoorlakshya Lakshya Kapoor added a comment - I investigated this issue and looks like it introduced by the  Pipeline: Declarative  plugin v1.3.5. The offending commit seems to be  https://github.com/jenkinsci/pipeline-model-definition-plugin/commit/39c7ed1e153bc3ae10a8aaf77ccc3bc7da2dc93a . Downgrading to v1.3.4.1 is the workaround for now.
            Hide
            pzozobrado Philip Zozobrado added a comment -

            ^^ I can confirm, symptoms arise upgrading to 1.3.5. I updated an older Jenkins to 1.3.5 and it resulted in the same symptoms. Downgrading back to 1.3.4.1 resolved it.

            Show
            pzozobrado Philip Zozobrado added a comment - ^^ I can confirm, symptoms arise upgrading to 1.3.5. I updated an older Jenkins to 1.3.5 and it resulted in the same symptoms. Downgrading back to 1.3.4.1 resolved it.
            Hide
            dnusbaum Devin Nusbaum added a comment - - edited

            Lakshya Kapoor Yes, this is caused by PR 313, which was the fix for JENKINS-55459. In general, you cannot use currentBuild.result to accurately determine the current state of the build, because currentBuild.result does not take into account any in-flight exceptions that are propagating throughout the execution and will cause it to result in failure at the top-level. Post conditions in Declarative do account for these in-flight exceptions and should be triggered appropriately. Getting and/or setting the build result is somewhat messy in Scripted Pipeline as well and does not always do what you want because there is no step-level build result, only an overall build result. The changes made in PR 313 made Declarative match the behavior of Scripted.

            What is your actual use case? Can you use post conditions without actually inspecting the build result? Perhaps we could provide some other kind of API visible to scripts to expose the ephemeral result that will be used when deciding what POST steps to run, but if you are setting the build result intentionally to try and change the flow of execution then I am not sure what we could do to fix that use case. CC Andrew Bayer

            Show
            dnusbaum Devin Nusbaum added a comment - - edited Lakshya Kapoor Yes, this is caused by PR 313 , which was the fix for JENKINS-55459 . In general, you cannot use currentBuild.result to accurately determine the current state of the build, because currentBuild.result does not take into account any in-flight exceptions that are propagating throughout the execution and will cause it to result in failure at the top-level. Post conditions in Declarative do account for these in-flight exceptions and should be triggered appropriately. Getting and/or setting the build result is somewhat messy in Scripted Pipeline as well and does not always do what you want because there is no step-level build result, only an overall build result. The changes made in PR 313 made Declarative match the behavior of Scripted. What is your actual use case? Can you use post conditions without actually inspecting the build result? Perhaps we could provide some other kind of API visible to scripts to expose the ephemeral result that will be used when deciding what POST steps to run, but if you are setting the build result intentionally to try and change the flow of execution then I am not sure what we could do to fix that use case. CC Andrew Bayer
            dnusbaum Devin Nusbaum made changes -
            Component/s pipeline-model-definition-plugin [ 21706 ]
            Component/s pipeline [ 21692 ]
            dnusbaum Devin Nusbaum made changes -
            Link This issue relates to JENKINS-55459 [ JENKINS-55459 ]
            Hide
            pzozobrado Philip Zozobrado added a comment - - edited

            Devin Nusbaum Does all what you said also apply to currentBuild.currentResult ? It's also showing incorrectly on failed stages.

            Can you use POST conditions without actually inspecting the build result?

            I'd like to answer your question with another question: How do we get a build status when inspecting currentBuild if result and currentResult are both incorrect on a build failure?

            Wouldn't this also make resultIsBetterOrEqualTo and resultIsWorseOrEqualTo now moot since we can no longer rely on any build status checks?

            Show
            pzozobrado Philip Zozobrado added a comment - - edited Devin Nusbaum Does all what you said also apply to currentBuild.currentResult ? It's also showing incorrectly on failed stages. Can you use POST conditions without actually inspecting the build result? I'd like to answer your question with another question: How do we get a build status when inspecting currentBuild if result and currentResult are both incorrect on a build failure? Wouldn't this also make resultIsBetterOrEqualTo and resultIsWorseOrEqualTo now moot since we can no longer rely on any build status checks?
            Hide
            dnusbaum Devin Nusbaum added a comment -

            Does all what you said also apply to currentBuild.currentResult

            Yes, currentBuild.getCurrentResult() is identical to currentBuild.getResult() except for the fact that it defaults to SUCCESS instead of null if the build result has not yet been set, see the code here.

            How do we get a build status when inspecting `currentBuild` if `result` and `currentResult` are both incorrect on a build failure?

            As far as I am aware, there is no way in Declarative to get an accurate picture of the current build status using only currentBuild. In Scripted, I think you could use try/catch statements along with currentBuild to look at the current status and catch specific kinds of exceptions to handle status-conditional logic, essentially duplicating this logic in Declarative. In Declarative, you should be able to use post conditions to handle status-conditional logic without needing to use currentBuild directly. I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases.

            Show
            dnusbaum Devin Nusbaum added a comment - Does all what you said also apply to currentBuild.currentResult Yes, currentBuild.getCurrentResult() is identical to currentBuild.getResult() except for the fact that it defaults to SUCCESS instead of null if the build result has not yet been set, see the code here . How do we get a build status when inspecting `currentBuild` if `result` and `currentResult` are both incorrect on a build failure? As far as I am aware, there is no way in Declarative to get an accurate picture of the current build status using only currentBuild . In Scripted, I think you could use try/catch statements along with currentBuild to look at the current status and catch specific kinds of exceptions to handle status-conditional logic, essentially duplicating this logic in Declarative . In Declarative, you should be able to use post conditions to handle status-conditional logic without needing to use currentBuild directly. I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases.
            Hide
            pzozobrado Philip Zozobrado added a comment - - edited

            I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases.

            I use currentBuild extensively to get the build's information, following some examples from here: https://www.christopherrung.com/2017/05/04/slack-build-notifications/

            It's a notification prettier to send Slack messages about the build's status at the point of success, failure, etc. While they don't directly use result in the code, we used POST

                 always { notifySlack(currentbuild.result) }
            

            as a catch-all for build statuses. currentBuild is, however, extensively used for grabbing test results and result details.

            Show
            pzozobrado Philip Zozobrado added a comment - - edited I asked about your exact use case because I am curious if there is a functionality gap we can address so that users would have no reason to use currentBuild given its confusing edge cases. I use currentBuild extensively to get the build's information, following some examples from here: https://www.christopherrung.com/2017/05/04/slack-build-notifications/ It's a notification prettier to send Slack messages about the build's status at the point of success, failure, etc. While they don't directly use result in the code, we used POST always { notifySlack(currentbuild.result) } as a catch-all for build statuses. currentBuild is, however, extensively used for grabbing test results and result details.
            Hide
            kapoorlakshya Lakshya Kapoor added a comment - - edited

            Hi Devin Nusbaum, my use case is similar to Philip Zozobrado's. I am sending an email notification in my post step (always) and I am using currentBuild.currentResult to determine the font color for the build status and the subject line in the email:

            def statusColor = colorCodeByStatus(currentBuild.currentResult) // $BUILD_STATUS font color
            
            ...
            
            // Returns HEX code based on given build status
            def colorCodeByStatus(status) {
              if(status == 'SUCCESS') {
                '#28B463' // Green
                
              } else if(status == 'FAILURE') {
                '#DF0101' // Red
            
              } else { // Aborted or Unstable
                '#9E9E9E' // Gray
              }
            }
            

            I am not sure if this violates any sort of best practices, but this could be a workaround for such use cases:

            post {
              success {
                  currentBuild.currentResult = 'SUCCESS'
              }
              unstable {
                  currentBuild.currentResult = 'UNSTABLE'
              }
              failure {
                  currentBuild.currentResult = 'FAILURE'
              }
              always {
                dir(path: 'report') {
                  executePostSteps(JOB_NAME)
                }
              }
            } // post
            

            I haven't had a chance to test it yet, so please feel free to critique it.

            Show
            kapoorlakshya Lakshya Kapoor added a comment - - edited Hi Devin Nusbaum , my use case is similar to Philip Zozobrado 's. I am sending an email notification in my post step ( always ) and I am using currentBuild.currentResult to determine the font color for the build status and the subject line in the email: def statusColor = colorCodeByStatus(currentBuild.currentResult) // $BUILD_STATUS font color ... // Returns HEX code based on given build status def colorCodeByStatus(status) { if (status == 'SUCCESS' ) { '#28B463' // Green } else if (status == 'FAILURE' ) { '#DF0101' // Red } else { // Aborted or Unstable '#9E9E9E' // Gray } } I am not sure if this violates any sort of best practices, but this could be a workaround for such use cases: post { success { currentBuild.currentResult = 'SUCCESS' } unstable { currentBuild.currentResult = 'UNSTABLE' } failure { currentBuild.currentResult = 'FAILURE' } always { dir(path: 'report' ) { executePostSteps(JOB_NAME) } } } // post I haven't had a chance to test it yet, so please feel free to critique it.
            Hide
            pzozobrado Philip Zozobrado added a comment - - edited

            Lakshya Kapoor, unfortunately, always runs first. That won't work:

            The condition blocks are executed in the order shown below.
            always, changed, fixed, regression, aborted, failure, success, unstable, unsuccessful, and cleanup.

            There's also some waterfalling not documented: fixed will also run success, for example.

            I've updated my pipeline to:

                    post {
                        cleanup {
                            cleanWs()
                        }
                        failure {
                            notifySlack([status  : 'FAILURE',
                                         pipeline: this] as JenkinsStatus)
                        }
                        fixed {
                            notifySlack([status  : 'FIXED',
                                         pipeline: this] as JenkinsStatus)
                        }
                        unstable {
                            notifySlack([status  : 'UNSTABLE',
                                         pipeline: this] as JenkinsStatus)
                        }
                        success {
                            notifySlack([status  : 'SUCCESS',
                                         pipeline: this] as JenkinsStatus)
                        }
                    }
            

            However, I'm still looking for a way to kill the fixed waterfall into success.

            Show
            pzozobrado Philip Zozobrado added a comment - - edited Lakshya Kapoor , unfortunately, always runs first. That won't work: https://jenkins.io/doc/book/pipeline/syntax/#post The condition blocks are executed in the order shown below. always, changed, fixed, regression, aborted, failure, success, unstable, unsuccessful, and cleanup. There's also some waterfalling not documented: fixed will also run success , for example. I've updated my pipeline to: post { cleanup { cleanWs() } failure { notifySlack([status : 'FAILURE' , pipeline: this ] as JenkinsStatus) } fixed { notifySlack([status : 'FIXED' , pipeline: this ] as JenkinsStatus) } unstable { notifySlack([status : 'UNSTABLE' , pipeline: this ] as JenkinsStatus) } success { notifySlack([status : 'SUCCESS' , pipeline: this ] as JenkinsStatus) } } However, I'm still looking for a way to kill the fixed waterfall into success .
            Hide
            dnusbaum Devin Nusbaum added a comment - - edited

            Lakshya Kapoor Your workaround won't work as Philip Zozobrado pointed out because always runs first, however cleanup has the same semantics as always other than running last, so you can probably use it for your workaround as they demonstrated.

            Philip Zozobrado Fall-through happens for changed, fixed, and regression, (and always, unsuccessful, and cleanup, but those are probably less interesting). The reason is that in Jenkins these conditions are not a first-class result, so Declarative computes them based on the current build status in comparison to the previous build's result, so one of aborted, failure, success, unstable, or notBuilt will always be executed if one of changed, fixed, or regression is executed. More than one of aborted, failure, success, unstable, and notBuilt will not be executed in the same post block.

            I think that it would be possible to support the use cases you both have mentioned by creating a new read-only variable that would only be set inside of post conditions in Declarative that would represent the current logical build status versus currentBuild.result which is just the literal value of Run.result. That way you would be able to access the current build status without Declarative needing to modify Run.result which is problematic in some cases.

            Show
            dnusbaum Devin Nusbaum added a comment - - edited Lakshya Kapoor Your workaround won't work as Philip Zozobrado pointed out because always runs first, however cleanup has the same semantics as always other than running last, so you can probably use it for your workaround as they demonstrated. Philip Zozobrado Fall-through happens for changed, fixed, and regression, (and always, unsuccessful, and cleanup, but those are probably less interesting). The reason is that in Jenkins these conditions are not a first-class result, so Declarative computes them based on the current build status in comparison to the previous build's result, so one of aborted, failure, success, unstable, or notBuilt will always be executed if one of changed, fixed, or regression is executed. More than one of aborted, failure, success, unstable, and notBuilt will not be executed in the same post block. I think that it would be possible to support the use cases you both have mentioned by creating a new read-only variable that would only be set inside of post conditions in Declarative that would represent the current logical build status versus currentBuild.result which is just the literal value of Run.result . That way you would be able to access the current build status without Declarative needing to modify Run.result which is problematic in some cases.
            kapoorlakshya Lakshya Kapoor made changes -
            Comment [ Test. ]
            Hide
            kapoorlakshya Lakshya Kapoor added a comment - - edited

            @Philip

            The condition blocks are executed in the order shown below.

            Yea, I had a feeling it was that way, but wasn't sure. Thanks for pointing it out!

            @Devin - I like your idea for the new read-only variable.

            P.S. JIRA is giving me a "Communications Breakdown" error when I @ your usernames . Was getting it since yesterday afternoon, but just figured it out it is related to tagging people.

            Show
            kapoorlakshya Lakshya Kapoor added a comment - - edited @Philip The condition blocks are executed in the order shown below. Yea, I had a feeling it was that way, but wasn't sure. Thanks for pointing it out! @Devin - I like your idea for the new read-only variable. P.S. JIRA is giving me a "Communications Breakdown" error when I @ your usernames . Was getting it since yesterday afternoon, but just figured it out it is related to tagging people.
            abayer Andrew Bayer made changes -
            Link This issue is duplicated by JENKINS-56430 [ JENKINS-56430 ]
            Hide
            chamshoff Christoph Amshoff added a comment -

            We run into this issue after last update of Jenkins core and plugins. It's highly critical because it results in wrong mails/notifications and changed behavior.

            Using currentBuild.result was a documented, working way of accessing the build result, also for declarative pipelines. It's not an option to change hundreds of pipelines in various branches and move code from always block to different post condition blocks. This would just duplicate a lot of code, like the call of emailext step.

            Moveover, the issue makes some plugins like claim-plugin unusable. This is called by step([$class: 'ClaimPublisher']) in the post section, and internally evaluates the build's status in order to decide whether to show claim functionality (build result is failure or unstalbe) or not; see ClaimPublisher.java:

             

            @Override
            public void perform(@Nonnull Run<?, ?> build, @Nonnull FilePath workspace, @Nonnull Launcher launcher,
                                @Nonnull TaskListener listener) throws InterruptedException, IOException {        
              Result runResult = build.getResult();
              if (runResult != null && runResult.isWorseThan(Result.SUCCESS)) {
                ...
              }
            }

            Since the result is always SUCCESS now, claim UI elements are never shown. Same applies to some custom plugins developed here.

            Thus, please restore the previous functionality ASAP! After that, you might think about better ways to fix the edge cases or provide new variables...

            Show
            chamshoff Christoph Amshoff added a comment - We run into this issue after last update of Jenkins core and plugins. It's highly critical because it results in wrong mails/notifications and changed behavior. Using currentBuild.result was a documented, working way of accessing the build result, also for declarative pipelines. It's not an option to change hundreds of pipelines in various branches and move code from always block to different post condition blocks. This would just duplicate a lot of code, like the call of emailext step. Moveover, the issue makes some plugins like claim-plugin unusable. This is called by step( [$class: 'ClaimPublisher'] ) in the post section, and internally evaluates the build's status in order to decide whether to show claim functionality (build result is failure or unstalbe) or not; see ClaimPublisher.java:   @Override public void perform(@Nonnull Run<?, ?> build, @Nonnull FilePath workspace, @Nonnull Launcher launcher, @Nonnull TaskListener listener) throws InterruptedException, IOException { Result runResult = build.getResult(); if (runResult != null && runResult.isWorseThan(Result.SUCCESS)) { ... } } Since the result is always SUCCESS now, claim UI elements are never shown. Same applies to some custom plugins developed here. Thus, please restore the previous functionality ASAP! After that, you might think about better ways to fix the edge cases or provide new variables...
            Hide
            michelzanini Michel Zanini added a comment - - edited

            Hi Devin Nusbaum,

            I used currentBuild.currentResult in a good number of places and was affected by this issue. I think we should revert it or provide an alternative way.
            I used it with at least 4 different plugins: Slack, MS Teams, Email Ext and InfluxDB.

            For Slack is basically similar to what has being described already:

            String slackMessage() {
              "Build *${env.JOB_NAME}* finished with status *${currentBuild.currentResult}*"
            }
            
            String slackColor() {
              "${currentBuild.currentResult == 'SUCCESS' ? 'good' : 'danger'}"
            }
            

            I don't want to have to repeat the above for each type of result, instead, is easier on the pipeline library to just read the status as above.

            For MS teams I have got:

            pipeline.office365ConnectorSend message: 'Build completed',
                    status: currentBuild.currentResult,
                    webhookUrl: msTeamsWebhookUrl,
                    color: currentBuild.currentResult == 'SUCCESS' ? '82C441' : 'C81423'
            

            Same use case as Slack.

            Another case with Slack and MS Teams is that we use a combination of lock and milestone plugins, so sometimes a build is skipped and the result is NOT_BUILT, so we have this:

            if (currentBuild.currentResult == 'NOT_BUILT') {
             //don't send Slack / MS Teams message in this case as this build has being skipped by lock/milestone
            }
            

            Now, the tricky cases are Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb).
            They need a value on currentBuild.result to function properly.
            So for both of them I have to do this before using the plugins:

            //to fix issue where mailer needs 'currentBuild.result' which is always null at this point - without this email does not report build result correctly
            currentBuild.result = currentBuild.currentResult
            
            step([$class: 'Mailer', recipients: emailList])
            

            And InfluxDB:

            //to fix issue where InfluxDbPublisher needs 'currentBuild.result' which is always null at this point - without this build result is not reported to InfluxDB
            currentBuild.result = currentBuild.currentResult
            
            step([$class: 'InfluxDbPublisher', target: 'influxdb'])
            

            Both Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb) are a bit old (they don't seem to support Declarative Pipelines directly, and instead we need to use step).

            After this bug was introduced I don't have an easy way of "fixing" this two plugins and all of the above cases stopped working for me.

            Show
            michelzanini Michel Zanini added a comment - - edited Hi Devin Nusbaum , I used currentBuild.currentResult in a good number of places and was affected by this issue. I think we should revert it or provide an alternative way. I used it with at least 4 different plugins: Slack, MS Teams, Email Ext and InfluxDB . For Slack is basically similar to what has being described already: String slackMessage() { "Build *${env.JOB_NAME}* finished with status *${currentBuild.currentResult}*" } String slackColor() { "${currentBuild.currentResult == 'SUCCESS' ? 'good' : 'danger' }" } I don't want to have to repeat the above for each type of result, instead, is easier on the pipeline library to just read the status as above. For MS teams I have got: pipeline.office365ConnectorSend message: 'Build completed' , status: currentBuild.currentResult, webhookUrl: msTeamsWebhookUrl, color: currentBuild.currentResult == 'SUCCESS' ? '82C441' : 'C81423' Same use case as Slack. Another case with Slack and MS Teams is that we use a combination of lock and milestone plugins, so sometimes a build is skipped and the result is NOT_BUILT, so we have this: if (currentBuild.currentResult == 'NOT_BUILT' ) { //don't send Slack / MS Teams message in this case as this build has being skipped by lock/milestone } Now, the tricky cases are Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb). They need a value on currentBuild.result to function properly. So for both of them I have to do this before using the plugins: //to fix issue where mailer needs 'currentBuild.result' which is always null at this point - without this email does not report build result correctly currentBuild.result = currentBuild.currentResult step([$class: 'Mailer' , recipients: emailList]) And InfluxDB: //to fix issue where InfluxDbPublisher needs 'currentBuild.result' which is always null at this point - without this build result is not reported to InfluxDB currentBuild.result = currentBuild.currentResult step([$class: 'InfluxDbPublisher' , target: 'influxdb' ]) Both Email Ext (plugin id = email-ext) and InfluxDB (plugin id = influxdb) are a bit old (they don't seem to support Declarative Pipelines directly, and instead we need to use step). After this bug was introduced I don't have an easy way of "fixing" this two plugins and all of the above cases stopped working for me.
            Hide
            chamshoff Christoph Amshoff added a comment -
            Show
            chamshoff Christoph Amshoff added a comment - Michel Zanini , for email-ext there is a Pipeline compatible step available, see https://jenkins.io/doc/pipeline/steps/email-ext/  and https://jenkins.io/blog/2017/02/15/declarative-notifications/
            Hide
            michelzanini Michel Zanini added a comment -

            Yes Christoph Amshoff, thanks. At the time I did this there was an issue with it, I don't remind what exactly, but yes I can try migrate, but not sure the problem with build result will go away....

            Show
            michelzanini Michel Zanini added a comment - Yes Christoph Amshoff , thanks. At the time I did this there was an issue with it, I don't remind what exactly, but yes I can try migrate, but not sure the problem with build result will go away....
            Hide
            pcarenza Peter Carenza added a comment -

            I agree with Christoph and Michael in that there's not just one, but several, plugins that break because of this change... and the change is often subtle. For instance, we didn't know about the false SUCCESS reports we were getting by email until we actually took a look at the log and found that the pipeline was actually failing.

            Granted, we're a small enough organization that uses just a few distributed pipelines and a standard jenkinsfile, so we were able to add a workaround, but for those like Cristoph who have to deal with hundreds of them, it's needless technical debt. 

            Show
            pcarenza Peter Carenza added a comment - I agree with Christoph and Michael in that there's not just one, but several, plugins that break because of this change... and the change is often subtle. For instance, we didn't know about the false SUCCESS reports we were getting by email until we actually took a look at the log and found that the pipeline was actually failing. Granted, we're a small enough organization that uses just a few distributed pipelines and a standard jenkinsfile, so we were able to add a workaround, but for those like Cristoph who have to deal with hundreds of them, it's needless technical debt. 
            Hide
            steffen_wilke Steffen Wilke added a comment -

            For us, this issue is equally urgent as for Christoph Amshoff. I agree with Michel Zanini on the approach to "revert it or provide an alternative way." Right now, this change caused developers to be notified with a "Build Completed" Email in our infrastructure, even though the build actually failed.

            I just wish there would be something like an LTS release line for these deeply integrated plugins. This would greatly increase their reliability.

            Show
            steffen_wilke Steffen Wilke added a comment - For us, this issue is equally urgent as for Christoph Amshoff . I agree with Michel Zanini on the approach to "revert it or provide an alternative way." Right now, this change caused developers to be notified with a "Build Completed" Email in our infrastructure, even though the build actually failed. I just wish there would be something like an LTS release line for these deeply integrated plugins. This would greatly increase their reliability.
            steffen_wilke Steffen Wilke made changes -
            Priority Major [ 3 ] Critical [ 2 ]
            steffen_wilke Steffen Wilke made changes -
            Environment Jenkins 2.150.3, Pipeline 2.6, using a slave build executioner Jenkins 2.150.3, Pipeline 2.6, Pipeline: Declarative plugin v1.3.5, using a slave build executioner
            Hide
            callum_p Callum Pember added a comment - - edited

            +1. We have jobs that rely on this, e.g. compare previous build against current build, set slack message color, etc etc. As it stands, it seems there is no way to determine if the build is failing right now, even with the hudson API? I had to add a function to read the build log

            Show
            callum_p Callum Pember added a comment - - edited +1. We have jobs that rely on this, e.g. compare previous build against current build, set slack message color, etc etc. As it stands, it seems there is no way to determine if the build is failing right now, even with the hudson API? I had to add a function to read the build log
            Hide
            jsmith45 Joe Smith added a comment -

            I understand that setting currentBuild.status for stage-level post conditions could potentially be problematic.

            But for the overall post conditions of the build there seems to be little reason not to set it if the build as a whole is failed. 
            This is the point point where people are most likely to use various plugins originally designed for freestyle projects that expect a result to be set. Some of them have been upgraded to treat an unset status value as success, which means that they worked fine in an overall post-build step, prior to the recent change, but don't anymore.

            In the alternative, at the very minimum the read only value proposed would help. In practice people would just use it to
            initialize currentBuild.result though, in order to make various legacy plugins happy.

            Show
            jsmith45 Joe Smith added a comment - I understand that setting currentBuild.status for stage-level post conditions could potentially be problematic. But for the overall post conditions of the build there seems to be little reason not to set it if the build as a whole is failed.  This is the point point where people are most likely to use various plugins originally designed for freestyle projects that expect a result to be set. Some of them have been upgraded to treat an unset status value as success, which means that they worked fine in an overall post-build step, prior to the recent change, but don't anymore. In the alternative, at the very minimum the read only value proposed would help. In practice people would just use it to initialize currentBuild.result though, in order to make various legacy plugins happy.
            Hide
            abayer Andrew Bayer added a comment -

            I've just merged a potential fix (https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/319) and am cutting 1.3.7-beta-1 now - see https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/ for how you can install the beta. It should be in the update center within an hour or so. We'd appreciate your feedback as to how this change works for you - if it turns out not to solve enough of the use cases, we'll switch to reverting the problematic change completely, but we'd really like to be able to keep it in if we can. Thanks, and we appreciate your patience and are very sorry for the inconvenience this change has caused.

            Show
            abayer Andrew Bayer added a comment - I've just merged a potential fix ( https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/319 ) and am cutting 1.3.7-beta-1 now - see https://jenkins.io/doc/developer/publishing/releasing-experimental-updates/ for how you can install the beta. It should be in the update center within an hour or so. We'd appreciate your feedback as to how this change works for you - if it turns out not to solve enough of the use cases, we'll switch to reverting the problematic change completely, but we'd really like to be able to keep it in if we can. Thanks, and we appreciate your patience and are very sorry for the inconvenience this change has caused.
            Hide
            kapoorlakshya Lakshya Kapoor added a comment - - edited

            Thanks, Andrew Bayer and Devin Nusbaum! I'll test 1.3.7-beta-1 on Monday and report back.

            Show
            kapoorlakshya Lakshya Kapoor added a comment - - edited Thanks, Andrew Bayer and Devin Nusbaum ! I'll test 1.3.7-beta-1 on Monday and report back.
            Hide
            chamshoff Christoph Amshoff added a comment -

            I've installed 1.3.7-beta-1 version of all four pipeline plugins (Pipeline: Declarative, Pipeline: Declarative Extension Points API, Pipeline: Model API and Pipeline: Stage Tags Metadata) and can confirm that it works! Status in post action is correcct now, mails are sent with proper status and Claims plugin's icon shows up again for unstable or failed builds.

            So, thanks for the fix! I really appreciate your efforts, and can imagine it's hard to fix this messy status implementation without breaking any functionality...

            Show
            chamshoff Christoph Amshoff added a comment - I've installed 1.3.7-beta-1 version of all four pipeline plugins (Pipeline: Declarative, Pipeline: Declarative Extension Points API, Pipeline: Model API and Pipeline: Stage Tags Metadata) and can confirm that it works! Status in post action is correcct now, mails are sent with proper status and Claims plugin's icon shows up again for unstable or failed builds. So, thanks for the fix! I really appreciate your efforts, and can imagine it's hard to fix this messy status implementation without breaking any functionality...
            Hide
            hellspam Roy Arnon added a comment -

            Just wanted to remark that the currentBuild.resultIsBetterOrEqualTo / resultIsWorseOrEqualTo also does not work because of the same issue - assuming they use the same currentBuild.currentResult internally.

            Show
            hellspam Roy Arnon added a comment - Just wanted to remark that the currentBuild.resultIsBetterOrEqualTo / resultIsWorseOrEqualTo also does not work because of the same issue - assuming they use the same currentBuild.currentResult internally.
            Hide
            steffen_wilke Steffen Wilke added a comment -

            1.3.7-beta-1 also fixed the issue for our infrastructure: Andrew Bayer Devin Nusbaum thank you very much for the fast response and fix!

            Show
            steffen_wilke Steffen Wilke added a comment - 1.3.7-beta-1  also fixed the issue for our infrastructure:  Andrew Bayer Devin Nusbaum thank you very much for the fast response and fix!
            Hide
            michelzanini Michel Zanini added a comment -

            1.3.7-beta-1 is a very good improvement. Not just it works like before, it also works better.

            Now I won't need to do this anymore:

            currentBuild.result = currentBuild.currentResult
            

            To make it easy for everyone to see differences between the versions. I will post the result of executing the pipeline that is on the description of this issue below, on all different versions, so people can easily spot the differences.

            1.3.4.1 and below:

            Init result: null
            Init currentResult: SUCCESS
            
            Post-Init result: null
            Post-Init currentResult: SUCCESS
            
            During Build result: null
            During Build currentResult: SUCCESS
            
            Post-Build result: FAILURE
            Post-Build currentResult: FAILURE
            
            Pipeline result: FAILURE
            Pipeline currentResult: FAILURE
            

            Note: problem with 1.3.6 is that it shows 'Post-Init result: null' where at that point it could be SUCCESS

            1.3.6:

            Init result: null
            Init currentResult: SUCCESS
            
            Post-Init result: null
            Post-Init currentResult: SUCCESS
            
            During Build result: null
            During Build currentResult: SUCCESS
            
            Post-Build result: null
            Post-Build currentResult: SUCCESS
            
            Pipeline result: null
            Pipeline currentResult: SUCCESS
            

            Note: This is the worse version because result is always 'null' and currentResult always 'SUCCESS'

            1.3.7-beta-1:

            Init result: null
            Init currentResult: SUCCESS
            
            Post-Init result: SUCCESS
            Post-Init currentResult: SUCCESS
            
            During Build result: null
            During Build currentResult: SUCCESS
            
            Post-Build result: FAILURE
            Post-Build currentResult: FAILURE
            
            Pipeline result: FAILURE
            Pipeline currentResult: FAILURE
            

            Note: this is the best version because both property are always correct on post blocks

            Show
            michelzanini Michel Zanini added a comment - 1.3.7-beta-1 is a very good improvement. Not just it works like before, it also works better. Now I won't need to do this anymore: currentBuild.result = currentBuild.currentResult To make it easy for everyone to see differences between the versions. I will post the result of executing the pipeline that is on the description of this issue below, on all different versions, so people can easily spot the differences. 1.3.4.1 and below : Init result: null Init currentResult: SUCCESS Post-Init result: null Post-Init currentResult: SUCCESS During Build result: null During Build currentResult: SUCCESS Post-Build result: FAILURE Post-Build currentResult: FAILURE Pipeline result: FAILURE Pipeline currentResult: FAILURE Note: problem with 1.3.6 is that it shows 'Post-Init result: null' where at that point it could be SUCCESS 1.3.6 : Init result: null Init currentResult: SUCCESS Post-Init result: null Post-Init currentResult: SUCCESS During Build result: null During Build currentResult: SUCCESS Post-Build result: null Post-Build currentResult: SUCCESS Pipeline result: null Pipeline currentResult: SUCCESS Note: This is the worse version because result is always 'null' and currentResult always 'SUCCESS' 1.3.7-beta-1 : Init result: null Init currentResult: SUCCESS Post-Init result: SUCCESS Post-Init currentResult: SUCCESS During Build result: null During Build currentResult: SUCCESS Post-Build result: FAILURE Post-Build currentResult: FAILURE Pipeline result: FAILURE Pipeline currentResult: FAILURE Note: this is the best version because both property are always correct on post blocks
            Hide
            kapoorlakshya Lakshya Kapoor added a comment -

            I am also glad to confirm that currentBuild.currentResult in v1.3.7-beta1 works as it did in v1.3.4.1. Thanks again!

            Show
            kapoorlakshya Lakshya Kapoor added a comment - I am also glad to confirm that currentBuild.currentResult in v1.3.7-beta1 works as it did in v1.3.4.1. Thanks again!
            danielbeck Daniel Beck made changes -
            Link This issue is duplicated by JENKINS-56536 [ JENKINS-56536 ]
            Hide
            kostrzewa9ld Zbigniew Kostrzewa added a comment -

            Does anyone know when 1.3.7 will be released?

            Show
            kostrzewa9ld Zbigniew Kostrzewa added a comment - Does anyone know when 1.3.7 will be released?
            Hide
            abayer Andrew Bayer added a comment -

            Hopefully this week - we’re trying to solve a bug in the original fix that created this problem in the first place, but if we aren’t able to nail that down in the next couple days, I’ll release 1.3.7 as it is now.

            Show
            abayer Andrew Bayer added a comment - Hopefully this week - we’re trying to solve a bug in the original fix that created this problem in the first place, but if we aren’t able to nail that down in the next couple days, I’ll release 1.3.7 as it is now.
            bkihm Benjamin Kihm made changes -
            Link This issue causes JENKINS-44322 [ JENKINS-44322 ]
            Hide
            abayer Andrew Bayer added a comment -

            Released just now as 1.3.7 - let us know if you see any problems and we'll get on them ASAP!

            Show
            abayer Andrew Bayer added a comment - Released just now as 1.3.7 - let us know if you see any problems and we'll get on them ASAP!
            abayer Andrew Bayer made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            flx Felix Retter added a comment -

            Thanks Andrew. 1.3.7 looks very promising

            Show
            flx Felix Retter added a comment - Thanks Andrew. 1.3.7 looks very promising
            dnusbaum Devin Nusbaum made changes -
            Released As pipeline-model-definition 1.3.7
            dnusbaum Devin Nusbaum made changes -
            Link This issue is duplicated by JENKINS-56590 [ JENKINS-56590 ]

              People

              • Assignee:
                Unassigned
                Reporter:
                pzozobrado Philip Zozobrado
              • Votes:
                23 Vote for this issue
                Watchers:
                40 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: