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

Getting an accurate build result when sending a notification from Pipeline is harder than it needs to be

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      There are some cases where the email-ext plugin incorrectly reports the "current" build status. I'm still not sure if this is a (scripted) pipeline restriction or a problem in email-ext. For my company it became especially bad now with the update of pipeline-maven-plugin from 3.5.14 to 3.5.15 (based on its implementation of JENKINS-27395, https://github.com/jenkinsci/pipeline-maven-plugin/commit/cfe37eeb66c07fc81c286f78499acfdef7aa05ec) - This change now changed all "UNSTABLE" mails to "SUCCESS" mails, which totally confuses our developers

      The other case where I already implemented a workaround is when some step throws an exception:

       

      try {
        some
        build
        steps
      } catch (e) {
        // Workaround!
        currentBuild.result = 'FAILURE'
        throw e
      } finally {
        emailext ...
      }
      

      If there were some way to either let Jenkins update the global job status from the individual step status or postpone the emailext exection after Jenkins can determine if the pipeline was successful or not, that would help a lot...

       

        Attachments

          Issue Links

            Activity

            Hide
            slide_o_mix Alex Earl added a comment -

            email-ext can only check the getResult for the current build, there is not really a way (as far as I know) to know whether part of the pipeline has failed otherwise.

            Show
            slide_o_mix Alex Earl added a comment - email-ext can only check the getResult for the current build, there is not really a way (as far as I know) to know whether part of the pipeline has failed otherwise.
            Hide
            basil Basil Crow added a comment -

            This issue is not specific to the Email Extension plugin but is a general problem with any steps in Pipeline that need access to the build result while the Pipeline is running. The only workaround I am aware of is to write your Pipeline script as follows:

            import org.jenkinsci.plugins.workflow.steps.FlowInterruptedException
            
            currentBuild.result = 'SUCCESS'
            
            try {
              […]
            } catch (FlowInterruptedException fie) {
              currentBuild.result = fie.result.toString()
              throw fie
            } catch (err) {
              currentBuild.result = 'FAILURE'
              throw err
            } finally {
              // Perform actions that need access to the build result.
              […]
            }
            

            Catching FlowInterruptedException is necessarily in order to properly deal with builds that were aborted by the user. See this article for more information.

            Since this problem is not specific to the Email Extension plugin but rather a general problem with how the RunWrapper API defined in workflow-support is awkward to use, I am moving this to the workflow-support component, where the Pipeline maintainers can triage this issue appropriately.

            Show
            basil Basil Crow added a comment - This issue is not specific to the Email Extension plugin but is a general problem with any steps in Pipeline that need access to the build result while the Pipeline is running. The only workaround I am aware of is to write your Pipeline script as follows: import org.jenkinsci.plugins.workflow.steps.FlowInterruptedException currentBuild.result = 'SUCCESS' try { […] } catch (FlowInterruptedException fie) { currentBuild.result = fie.result.toString() throw fie } catch (err) { currentBuild.result = 'FAILURE' throw err } finally { // Perform actions that need access to the build result. […] } Catching FlowInterruptedException is necessarily in order to properly deal with builds that were aborted by the user. See this article for more information. Since this problem is not specific to the Email Extension plugin but rather a general problem with how the RunWrapper API defined in workflow-support is awkward to use, I am moving this to the workflow-support component, where the Pipeline maintainers can triage this issue appropriately.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              tgr Tobias Gruetzmacher
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated: