I'll research this.

I think this change should be fine.

Code changed in jenkins
User: Alex Earl
Path:
src/main/java/hudson/plugins/emailext/ExtendedEmailPublisher.java
http://jenkins-ci.org/commit/email-ext-plugin/e7bc7c814709e433d98fab1b31f340380043caf5
Log:
Fixed JENKINS-16376

• Changed to BuildStepMonitor.NONE

Changed to BuildStepMonitor.NONE

IMO we actually do need BuildStepMonitor.BUILD - e.g. if a 'fixed' trigger is used.
Otherwise you couldn't determin if a build is a fix for the previous build.

What we could do is:
check if we have a trigger which needs the previous build's result (fixed, still xyz) and only then require BuildStepMonitor.BUILD.
But I'm not sure if this would be worth the effort and not being more unintuitive to use.

I agree, I reverted. Wasn't thinking through the whole process. Need more sleep

Because of the nature of the triggers, this requires BuildStepMonitor.BUILD.

i have a similar problem, as this: https://issues.jenkins-ci.org/browse/JENKINS-10234 and as this.
if this is not going to be changed - is there an email plugin that does not have triggers depending on the BuildStepMonitor.BUILD. and is able to send mails concurrently?

The default mailer uses BuildStepMonitor.NONE.

There are a lot of different possible choices for what Email Ext should do when some aspect of the mail implies knowledge of the completed result of the previous build (as for example $DEFAULT_SUBJECT currently does, via $BUILD_STATUS). But it is pretty clear from user feedback that the current behavior—waiting for the previous build to complete—is the least popular choice possible. Jenkins may be running several three-hour test suites on different slaves, so having one that fails after ten minutes wait hours for the “previous” one to complete just so it can report the most precise possible status is crazy.

I would suggest switching back to NONE, which according to my inspection of the code (all uses of Run.getPreviousBuild) would have the effect of treating a running previous build much like a STABLE one, or as if the current build is the first for the project. For example, $BUILD_STATUS would be Successful, Failure, or Unstable, but not Fixed or Still unstable or Still failing. While this is not perfect, it seems acceptable enough; if you have chosen to permit your project to run concurrent builds, presumably you are not terribly interested in build-to-build comparisons, you just want to know how this build turned out.

If there is concern that this behavior would be confusing to anyone, it would be easy enough to add some sort of notification: form validation when configuring the job noting that currently requested elements might vary according to the previous build result (if the concurrent builds checkbox is also ticked on the project’s configuration screen); or a warning in the console output when email is being sent but the previous build is still running (possibly restricted to token macros which were checking that previous build); or notification in the email itself, e.g. having $BUILD_STATUS read Successful (previous build still running).

The plugin could also skip over still-running builds and consider only the latest preceding completed build, though it is not clear this is any more intuitive: you could for example get two Fixed mails in a row.

I would volunteer to file a pull request for one of these behaviors if the plugin maintainers agree that a change would be desirable. (Of all the possibilities, a warning in the console output seems easiest.)

When this was tried in the past, it caused all sorts of weird corner cases. It would have to have a lot of testing done before I would consider merging anything.

What sort of corner cases did you encounter?

Well, I guess I don't know if I would consider this a corner case, but all of the tests seemed to fail with a weird error.

I just tried changing BUILD to NONE and did not get any test failures.

I didn't get failures when building locally, but when I committed the change and BuildHive built it, everything failed (this was months ago, but that is my recollection). I don't know enough about Maven to say whether it is just a project setup issue or what.

Would you recommend changing everywhere that calls getPreviousBuild to check if its still building?

when I committed the change and BuildHive built it, everything failed

Might have been an unrelated infrastructure issue.

Would you recommend changing everywhere that calls getPreviousBuild to check if its still building?

That was implied by my second and third suggestions:

a warning in the console output when email is being sent but the previous build is still running (possibly restricted to token macros which were checking that previous build); or notification in the email itself, e.g. having $BUILD_STATUS read Successful (previous build still running)

There are some content tokens that iterate back through builds such as the ChangesSinceLastSuccessfulBuildContent and a few others. What would the expected behavior be in that case?

I would be inclined to make those simply stop searching (and perhaps emit a warning) when encountering a prior build which is still building. As with other tokens under question, if you are using concurrent builds you probably cannot sensibly use this anyway.

Again, I am willing to file a pull request if you agree with the general suggestion and are interested in hashing out details.

I already started on the implementation.

Is this still in progress?

Pull #79.

I'll review this as soon as possible and merge it.

Code changed in jenkins
User: Jesse Glick
Path:
src/main/java/hudson/plugins/emailext/ExtendedEmailPublisher.java
src/main/java/hudson/plugins/emailext/plugins/content/AbstractChangesSinceContent.java
src/main/java/hudson/plugins/emailext/plugins/content/BuildStatusContent.java
src/main/java/hudson/plugins/emailext/plugins/content/ChangesSinceLastBuildContent.java
src/main/java/hudson/plugins/emailext/plugins/content/ChangesSinceLastSuccessfulBuildContent.java
src/main/java/hudson/plugins/emailext/plugins/content/ChangesSinceLastUnstableBuildContent.java
src/main/java/hudson/plugins/emailext/plugins/trigger/BuildingTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/FixedTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/FixedUnhealthyTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/ImprovementTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/NthFailureTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/RegressionTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/StatusChangedTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/StillFailingTrigger.java
src/main/java/hudson/plugins/emailext/plugins/trigger/StillUnstableTrigger.java
src/main/resources/hudson/plugins/emailext/Messages.properties
src/test/java/hudson/plugins/emailext/ExtendedEmailPublisherTest.java
http://jenkins-ci.org/commit/email-ext-plugin/6fb41818d63ca0067171f8c01fcdbed196335b44
Log:
[FIXED JENKINS-16376] Never wait for previous builds to complete just to get a more precise status.
If and when we need to know the status of a previous build but it is still running,
simply print a warning to the (current build’s) log and proceed as if the previous build did not exist.

When do you plan the next release? This is the highly anticipated feature.

This is not fixed in 1.542.
We're waiting for this fix before we upgrade.
Changelog does not show this issue (or any of the duplicated/related issues) have ever been incorporated/released.
When will this fix be incorporated?

What do you mean 1.542? This is a bug against email-ext, not core. Email-ext does not have a version 1.542.

Sorry. I reached this issue from a different issue and thought it was still against Jenkins itself.
I meant Jenkins version 1.542.

I see from the email-ext changelog that version 2.37 has this fix in it.
We're using 2.36, so an update should fix this for us. Thanks!

We need this to be change for performance publisher plugin too. Can I contribute?

https://github.com/jenkinsci/performance-plugin/search?utf8=%E2%9C%93&q=BuildStepMonitor+getRequiredMonitorService

Thanks

Please open a new issue for the performance plugin. This issue is for email-ext.