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

[jenkins-infra-bot]

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">JENKINS-27395, jenkinsci/pipeline-maven-plugin@cfe37ee) - 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...

 

---

Originally reported by tgr, imported from: Getting an accurate build result when sending a notification from Pipeline is harder than it needs to be

• status: Open
• priority: Major
• component(s): workflow-support-plugin
• resolution: Unresolved
• votes: 0
• watchers: 3
• imported: 20260601-173816

Raw content of original issue

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, jenkinsci/pipeline-maven-plugin@cfe37ee) - 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-infra-bot]

slide_o_mix:

• Original comment link
• Raw content of original 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.
  

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.

[jenkins-infra-bot]

basil:

• Original comment link
• Raw content of original 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.
  

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.