It seems this is also true for `SUCCESS` which is set only after the build has completed (and after all post sections), but using `currentBuild.result` inside of a post section returns `null`.

This also happens for builds that are Superseded (when using milestones).  When I get the current result status in the failure block it says "FAILURE" but the build final status is NOT_BUILT. (Same for ABORTED as above).

It's also incorrectly reporting as a completeBuild - which is an additional check that I'm performing.

Getting the previous build does return the correct result.

Interesting! We're setting the build result to FAILURE explicitly when we encounter an exception in execution of a stage, but I'm guessing that's not the ideal behavior for these scenarios. I'll investigate.

Thank you

Tada - PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/153.

Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/pom.xml
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/Utils.groovy
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/NotBuilt.groovy
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineFromDockerfileScript.groovy
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineScript.groovy
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/LabelScript.groovy
pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/model/conditions/Messages.properties
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/BasicModelDefTest.java
pom.xml
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/d9a8fb10d9c830470dfb9871696ca9df8c50f0f7
Log:
[FIXED JENKINS-43339] Properly set result from FlowInterruptedException

We should be setting the build result to
FlowInterruptedException.getResult() when we catch a
FlowInterruptedException, since there's actually a relevant result
there. Also added a notBuilt post status while I was here.

Released in 1.1.4 just now!

I looked forward to this change, but my related problem is not fixed

http://stackoverflow.com/questions/42973501/declarative-pipeline-donts-send-post-failure-notificaitons-if-build-was-abbort

romanp I've been having the same problem as you and for me the issue you describe in stackoverflow was resolved with 1.1.4.

seems working again after restarting jenkins (maybe I've missed this after installing).
sorry for any inconvenience.

This issue still persist for us. We have script e.g.

node {
    def repoGitUrl = "git@usfr-git.foo.git"

    jdk "JDK8"

    catchError {
        dir('FOO') {
            stage "Checkout"
            gitCheckout(repoGitUrl, "master")

            stage "Merge"
            def gitflow = new com.foo.GitFlow()
            gitflow.mergeMasterToOtherBranches()

            deleteDir()
        }

        currentBuild.result = 'SUCCESS'
    }

    mailOnFailure("foo@bar.com")
}

def call(gitlab, branch) {
    checkout([
            $class                           : 'GitSCM',
            branches                         : [[name: "${branch}"]],
            doGenerateSubmoduleConfigurations: false,
            extensions                       : [
                    [$class: 'WipeWorkspace'],
                    [$class: 'CleanBeforeCheckout'],
                    [$class: 'LocalBranch', localBranch: "${branch}"]
            ],
            submoduleCfg                     : [],
            userRemoteConfigs                : [
                    [
                            credentialsId: 'GitLabBuildUser',
                            url          : "${gitlab}"
                    ]
            ]
    ])
}

def call(recipients) {
    if (currentBuild.result != 'ABORTED') { // don't send email when the build was aborted
        step([$class                  : 'Mailer',
              notifyEveryUnstableBuild: true,
              recipients              : recipients,
              sendToIndividuals       : true])
    }
}

When I abort the Jenkins job while it is checking out, the currentBuild.result is FAILURE, not ABORTED as expected. Git checkout throws a java.lang.InterruptedException and then the currentBuild.result contains FAILURE, not ABORTED.

Full log: https://pastebin.com/B5AFZnN9

Also confirming this error with declarative pipelines. When I abort the build the post-build action for failure triggers, not abort.  

Final two lines of console log show:

ERROR: script returned exit code 143
Finished: ABORTED

Jenkins 2.93. 
Latest pipeline plugins all installed as of this date. 

Regrettably, not much we can do here - the ABORTED status, in some cases, doesn't get set until the Pipeline finishes executing, so we can't tell from Declarative that we should be treating the build as ABORTED.

abayer, rather than just saying this won't be fixed, perhaps it is better to remove features that provide the illusion that `ABORTED` is a supported state that can be handled in declarative pipelines? Then there will be no confusion

(I suspect this issue will continue to be reported when someone else tries to handle `aborted` in a `post` block)

The thing is that ABORTED does work in some contexts, but not others. It's weird.

abayer I've observed the following:

When running parallel steps with fastFail set, the fast-failed aborted build will return FAILURE if the act of aborting a step that was still in progress returns an error code. 

However if other parallel steps have finished successfully, and the last running step fails, this correctly returns ABORTED in the event of failure.

Some kind of race condition where if a step fails, fastFail aborts all other steps, and the last error code returned is the status seen by the declarative pipeline, but isn't the one respected by the overall build.status? Hopefully that makes sense. 

Is there not a reliable way to get from the rawBuild if a build was aborted?
I cannot image that there's no way - as the builds are eventually - when they are totally finished - always displayed with the right result. 'Only' currentBuild.currentResult is very often giving a different result (FAILURE usually)
We're using this hack now to get better detection of aborted builds:

if (currentBuild.rawBuild.getActions(jenkins.model.InterruptedBuildAction.class).isEmpty()) {
   return currentBuild.currentResult
} else {
  return "ABORTED"
}

Bulk closing resolved issues.

Thanks kutzi – this workaround is indeed very helpful! (Of course one would prefer a proper/clean solution/fix... )

reinholdfuereder according to your comment, you still have experienced this issue in the current release?
I'm having the workaround in place and therefore not watching it anymore.
According to Liam's comment this should have been fixed?