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.

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

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

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?

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.

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.

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.

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.

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.

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

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.

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/

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

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. 

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.

+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

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.

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.

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

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.

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

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!

Does anyone know when 1.3.7 will be released?

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.

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

Thanks Andrew. 1.3.7 looks very promising

Bulk closing resolved issues.

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

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.

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

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.

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