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

`currentBuild.result` is not set to `ABORTED` when the build was aborted

    XMLWordPrintable

Details

    Description

      Right now when the build is aborted using the `pipeline-input-step` plugin in a declarative pipeline, the build result is set to `FAILURE` instead of `ABORTED` in the post section. However, the actual result is properly set to `ABORTED` afterwards. This makes it impossible to do conditional code in the post section.

      Attachments

        Issue Links

          Activity

            rochdev Roch Devost added a comment -

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

            rochdev Roch Devost added a comment - 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`.
            joc Jo Carter added a comment -

            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.

            joc Jo Carter added a comment - 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.
            abayer Andrew Bayer added a comment -

            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.

            abayer Andrew Bayer added a comment - 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.
            joc Jo Carter added a comment -

            Thank you

            joc Jo Carter added a comment - Thank you
            abayer Andrew Bayer added a comment - 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.

            scm_issue_link SCM/JIRA link daemon added a comment - 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.
            abayer Andrew Bayer added a comment -

            Released in 1.1.4 just now!

            abayer Andrew Bayer added a comment - Released in 1.1.4 just now!
            romanp Roman Pickl added a comment - 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.

            rbjorklin Robin Björklin added a comment - 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.
            romanp Roman Pickl added a comment -

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

            romanp Roman Pickl added a comment - 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")
            }
            
            The gitCheckout() function:
            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}"
                                ]
                        ]
                ])
            }
            
            The mailOnFailure() function:
            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

             

            Versions:

            pipeline-model-definition 1.1.9
            pipeline-input-step 2.7
            Jenkins 2.46.3

            akarola Antonín Karola added a comment - 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" ) } The gitCheckout() function: 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}" ] ] ]) } The mailOnFailure() function: 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   Versions: pipeline-model-definition 1.1.9 pipeline-input-step 2.7 Jenkins 2.46.3

            This happens for me right now as well with Jenkins 2.72.3. 

            pjohnston Phillip Johnston added a comment - This happens for me right now as well with Jenkins 2.72.3. 
            pwilcock Peter Wilcock added a comment -

            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. 

            pwilcock Peter Wilcock added a comment - 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. 
            abayer Andrew Bayer added a comment -

            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 Andrew Bayer added a comment - 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

            pjohnston Phillip Johnston added a comment - 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)

            pjohnston Phillip Johnston added a comment - (I suspect this issue will continue to be reported when someone else tries to handle `aborted` in a `post` block)
            abayer Andrew Bayer added a comment -

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

            abayer Andrew Bayer added a comment - The thing is that ABORTED does work in some contexts, but not others. It's weird.
            pwilcock Peter Wilcock added a comment - - edited

            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. 

            pwilcock Peter Wilcock added a comment - - edited 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. 
            kutzi kutzi added a comment - - edited

            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"
            }
            
            kutzi kutzi added a comment - - edited 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" }
            bitwiseman Liam Newman added a comment -

            Bulk closing resolved issues.

            bitwiseman Liam Newman added a comment - Bulk closing resolved issues.

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

            reinholdfuereder Reinhold Füreder added a comment - Thanks kutzi – this workaround is indeed very helpful! (Of course one would prefer a proper/clean solution/fix... )
            kutzi kutzi added a comment - - edited

            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?

            kutzi kutzi added a comment - - edited 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?

            People

              abayer Andrew Bayer
              rochdev Roch Devost
              Votes:
              6 Vote for this issue
              Watchers:
              26 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: