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

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

       

          [JENKINS-54477] Getting an accurate build result when sending a notification from Pipeline is harder than it needs to be

          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.

          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.

          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.

          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.

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

              Created:
              Updated: