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

Declarative Pipeline shows SUCCESS even though job FAILED

    • pipeline-model-definition 1.3.7

      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
      

       

          [JENKINS-56402] Declarative Pipeline shows SUCCESS even though job FAILED

          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.

          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.

          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.

          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.

          ^^ 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.

          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.

          Devin Nusbaum added a comment - - edited

          kapoorlakshya 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 abayer

          Devin Nusbaum added a comment - - edited kapoorlakshya 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 abayer

          Philip Zozobrado added a comment - - edited

          dnusbaum 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?

          Philip Zozobrado added a comment - - edited dnusbaum 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?

          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.

          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.

          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.

          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.

          Lakshya Kapoor added a comment - - edited

          Hi dnusbaum, my use case is similar to pzozobrado'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.

          Lakshya Kapoor added a comment - - edited Hi dnusbaum , my use case is similar to pzozobrado '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.

          Philip Zozobrado added a comment - - edited

          kapoorlakshya, 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.

          Philip Zozobrado added a comment - - edited kapoorlakshya , 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 .

          Devin Nusbaum added a comment - - edited

          kapoorlakshya Your workaround won't work as pzozobrado 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.

          pzozobrado 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.

          Devin Nusbaum added a comment - - edited kapoorlakshya Your workaround won't work as pzozobrado 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. pzozobrado 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.

          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.

          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.

          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...

          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...

          Michel Zanini added a comment - - edited

          Hi dnusbaum,

          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.

          Michel Zanini added a comment - - edited Hi dnusbaum , 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.

          Christoph Amshoff added a comment - michelzanini , 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/

          Michel Zanini added a comment -

          Yes chamshoff, 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....

          Michel Zanini added a comment - Yes chamshoff , 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....

          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. 

          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. 

          Steffen Wilke added a comment -

          For us, this issue is equally urgent as for chamshoff. I agree with michelzanini 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 added a comment - For us, this issue is equally urgent as for chamshoff . I agree with michelzanini 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.

          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

          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

          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.

          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.

          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.

          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.

          Lakshya Kapoor added a comment - - edited

          Thanks, abayer and dnusbaum! I'll test 1.3.7-beta-1 on Monday and report back.

          Lakshya Kapoor added a comment - - edited Thanks, abayer and dnusbaum ! I'll test 1.3.7-beta-1 on Monday and report back.

          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...

          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...

          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.

          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.

          Steffen Wilke added a comment -

          1.3.7-beta-1 also fixed the issue for our infrastructure: abayer dnusbaum thank you very much for the fast response and fix!

          Steffen Wilke added a comment - 1.3.7-beta-1  also fixed the issue for our infrastructure:  abayer dnusbaum thank you very much for the fast response and fix!

          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

          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

          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!

          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!

          Does anyone know when 1.3.7 will be released?

          Zbigniew Kostrzewa added a comment - Does anyone know when 1.3.7 will be released?

          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.

          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.

          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!

          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!

          Felix Retter added a comment -

          Thanks Andrew. 1.3.7 looks very promising

          Felix Retter added a comment - Thanks Andrew. 1.3.7 looks very promising

          Liam Newman added a comment -

          Bulk closing resolved issues.

          Liam Newman added a comment - Bulk closing resolved issues.

          Artour Klevin added a comment -

          With current version 1.5.0 of Pipeline: Declarative Plugin.
          I get the same issue.
           

          Artour Klevin added a comment - With current version 1.5.0 of Pipeline: Declarative Plugin. I get the same issue.  

          Devin Nusbaum added a comment -

          artour If you reopen an old issue, please include a full reproduction case of the issue you are seeing, and describe the actual and expected behavior. In this case, since the issue has been fixed since March, it would be better to open a new ticket to track whatever issue you are seeing separately, so I am going to re-close this issue.

          Devin Nusbaum added a comment - artour If you reopen an old issue, please include a full reproduction case of the issue you are seeing, and describe the actual and expected behavior. In this case, since the issue has been fixed since March, it would be better to open a new ticket to track whatever issue you are seeing separately, so I am going to re-close this issue.

          chirs damour added a comment -

          For people who reported watched this issue its nice that the issue is reopened because it gets it on our radar. Forcing A new issue is a disservice to your hard core issue reporting users who wouldnt get notified

          But totally should have recreate steps

          chirs damour added a comment - For people who reported watched this issue its nice that the issue is reopened because it gets it on our radar. Forcing A new issue is a disservice to your hard core issue reporting users who wouldnt get notified But totally should have recreate steps

          Devin Nusbaum added a comment -

          drdamour By all means, if you open a new issue that is related to an old issue, please comment on the old issue mentioning that you saw something similar, include a link to the new issue, and add a "relates to" issue link in Jira to the other issue. I think it is ok to reopen an issue if you do so very soon after it was originally resolved/closed, since the context is still the same, but given this issue was originally closed in March 2019, I think we need to reevaluate any related issue from scratch. For example, is the fix completely broken (hopefully not, we added some regression tests with the fix), is this a slightly different use case, does it only break when using matrix or parallel, etc.

          Devin Nusbaum added a comment - drdamour By all means, if you open a new issue that is related to an old issue, please comment on the old issue mentioning that you saw something similar, include a link to the new issue, and add a "relates to" issue link in Jira to the other issue. I think it is ok to reopen an issue if you do so very soon after it was originally resolved/closed, since the context is still the same, but given this issue was originally closed in March 2019, I think we need to reevaluate any related issue from scratch. For example, is the fix completely broken (hopefully not, we added some regression tests with the fix), is this a slightly different use case, does it only break when using matrix or parallel , etc.

          Artour Klevin added a comment -

          Sorry for just re-opening it without adding more information.
          It looked very similar to my problem, but after spending another day on it, I have no issues.

          I just set the curentBuild.result = 'FAILURE' in the catch when my step fails in the pipeline.
          Then everything works as I would like it to.

          Thanks for keeping the plugin alive! 

          Artour Klevin added a comment - Sorry for just re-opening it without adding more information. It looked very similar to my problem, but after spending another day on it, I have no issues. I just set the curentBuild.result = 'FAILURE' in the catch when my step fails in the pipeline. Then everything works as I would like it to. Thanks for keeping the plugin alive! 

          Bug, mentioned in the description of this task is still present on latest Jenkins (Jenkins 2.375.1):

          Failed in branch build_check
          currentBuild.result:null
          currentBuild.currentResult:SUCCESS
          ...
          Finished: FAILURE

          qwertytmp1 qwertytmp1 added a comment - Bug, mentioned in the description of this task is still present on latest Jenkins ( Jenkins 2.375.1 ): Failed in branch build_check currentBuild.result:null currentBuild.currentResult:SUCCESS ... Finished: FAILURE

            Unassigned Unassigned
            pzozobrado Philip Zozobrado
            Votes:
            23 Vote for this issue
            Watchers:
            42 Start watching this issue

              Created:
              Updated: