You can do this now with a groovy script.

Quoted from the mailing list:

// the goal is to find the top level job which should contain the changelist
def upstreamBuild = null
def cause = build.causes.find {
     if(it instanceof hudson.model.Cause.UpstreamCause) {
         return true
     }
     return false
}

while(cause != null) {
     upstreamBuild =
hudson.model.Hudson.instance.getItem(cause.upstreamProject).getBuildByNumber(cause.upstreamBuild)
     cause = upstreamBuild.causes.find {
         return (it instanceof hudson.model.Cause.UpstreamCause);
     }
}

Then I check if upstreamBuild is null or not, and if its not, I have
access to its information like this:

def changeSet = upstreamBuild.changeSet

And you can get the info you are looking for from there.

This can be done now with a SCRIPT content token in the recipients.

I would volunteer to implement this as a native feature of the plugin to keep it consistent with the existing trigger configuration, by just having a simple checkbox to activate this feature. This might be easier than a groovy script especially together with the configuration slicing plugin and when you have a couple of hundred/thousand builds to manage. I see the following options with decreasing preference.

1. Option 1:
   Add a new "Send to Upstream Committers"
   Main benefit is that it doesn't change existing functionality and is the most flexible one with regards to configuration
2. Option 2:
   Change behaviour of "Send To Culprits"
   You can say that when a build is triggered by a SCM change in a upstream build the committer(s) of the upstream build(s) might be the culprit(s). Drawback is that this changes the current behaviour.
3. Option 3:
   Change behaviour of "Send to Requester"
   You can say that when a build is triggered by a SCM change in a upstream build the committer(s) of the upstream build(s) might be the requester(s) although only implicitly. Drawback is the same as option 2 that this changes the current behaviour.

I have the implementation actually available, so I would like to hear your opinion which option you prefer.

Why have it native in the plugin if you can do it via the script token? There are different types of builds that putting it directly into the plugin could cause problems. With the script method, the person can tailor it to their setup.

Thanks for the quick feedback. What problems do you see, maybe I can take them into consideration? From an implementation point of view (which Jenkins API calls are made) it is very similar to "Send To Requester" and would be inline with JENKINS-7740.

For instance, more people are using the Build Flow plugin, the Upstream stuff doesn't work the same way with a Build Flow job as it does with a normal job. You have to access it differently.

But wouldn't this also apply for the groovy script, that one need different ways to retrieve the upstream builds and does this also not apply then to the build in "Send to Requester" feature which calculates the root upstream build using the Jenkins core feature and is not aware of the "Build Flow plugin"?

With the groovy script, each admin has the ability to tailor it to their needs, this is why I am advocating using a script instead of adding a new feature. "Send to Requester" actually sends to the person (if there was a person) that initiated the build. Are you thinking of Culprits or Developers? Culprits does have a similar issue, it will break if you are using a different project type that doesn't have the same layout as other projects (like Build Flow).

We have hundreds of developers maintaining their own Jenkins jobs on a central server. We can reasonably expect them to choose whether to hit a checkbox. We cannot expect them to learn Groovy on top of their other responsibilities.

How could it not be a good idea for the plugin to handle this natively? If the plugin handles it natively, with a checkbox as suggested by Christian, then admins have a choice of using the native implementation if it works for them. They also still have the option of using Groovy if they love lots of repeated code in each of their Jenkins jobs. Without native support in the plugin, there are no options.

Why would they need Gradle? The script is pure Groovy. There are plenty of ways to reduce the need for each person to know Groovy. You can create template jobs (plugin), when new jobs are created you create them based on a template (if you don't want a plugin).

Sorry, I meant Groovy. I've edited my previous comment.

I also have a way of reducing the need for each person to know Groovy: Provide a checkbox that offers this functionality natively.

Feel free to implement it and issue a pull request.

I implemented a change which is available in pull request https://github.com/jenkinsci/email-ext-plugin/pull/83.

The discussion on the pull request has led me to implement a RecipientProvider extension point. This will allow people to implement their own plugins that add functionality. It will be much easier for people to create pull requests with new ways of providing recipients. I hope to get it into the next release.

The RecipientProvider extension point has been released as part of 2.38.1, feel free to implement a plugin that implements a RecipientProvider, or create a new pull request based on the latest code.

This can be implemented by a plugin that implements a RecipientProvider, it will not be implemented in the email-ext plugin.

Thanks for providing the extension point. I will look into it the next days. W.r.t. your last two comments, would you be OK with a new pull request for this plugin or would you only see this as a new plugin?

You could do a pull request for the current plugin, that would be fine. I just don't have time to implement it.

Code changed in jenkins
User: Christian Galsterer
Path:
src/main/java/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider.java
src/main/resources/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider/help.html
http://jenkins-ci.org/commit/email-ext-plugin/f44a742850de3f133124612dd155a924e4115303
Log:
JENKINS-17742 - Pick Up Committer from Upstream Job

Code changed in jenkins
User: Christian Galsterer
Path:
src/main/java/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider.java
http://jenkins-ci.org/commit/email-ext-plugin/303a15e7fe2da246500cec32623b8b858cdbfe57
Log:
JENKINS-17742 - Pick Up Committer from Upstream Job

• fixed review comments (logging and spacing)

Code changed in jenkins
User: Christian Galsterer
Path:
src/main/java/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider.java
src/main/resources/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider/help.html
http://jenkins-ci.org/commit/email-ext-plugin/763ecc19519e6d14b35e0be4150f55d99a028850
Log:
JENKINS-17742 - Pick Up Committer from Upstream Job

Code changed in jenkins
User: Christian Galsterer
Path:
src/main/java/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider.java
http://jenkins-ci.org/commit/email-ext-plugin/56896689098d61a3aa79a1f54dff802f26388ff6
Log:
JENKINS-17742 - Pick Up Committer from Upstream Job

• fixed review comments (logging and spacing)

Code changed in jenkins
User: Christian Galsterer
Path:
src/main/java/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider.java
http://jenkins-ci.org/commit/email-ext-plugin/b87a57e244752fe1b9ac965f044b39d96d755862
Log:
JENKINS-17742 - Pick Up Committer from Upstream Job

• fixed review comment on display name

Code changed in jenkins
User: Christian Galsterer
Path:
http://jenkins-ci.org/commit/email-ext-plugin/4b19e9bfd1ce3d59975be52fd9287793408a2d1a
Log:
JENKINS-17742 - Pick Up Committer from Upstream Job

• I18N for display name

src/main/java/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider.java

Code changed in jenkins
User: Alex Earl
Path:
src/main/java/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider.java
src/main/resources/hudson/plugins/emailext/Messages.properties
src/main/resources/hudson/plugins/emailext/plugins/recipients/UpstreamComitterRecipientProvider/help.html
http://jenkins-ci.org/commit/email-ext-plugin/58f0a1ef125a361fc9045e05c93b1053932dc337
Log:
Merge pull request #91 from christiangalsterer/JENKINS-17742

JENKINS-17742 - Pick Up Committer from Upstream Job

Compare: https://github.com/jenkinsci/email-ext-plugin/compare/bfaadca29e5b...58f0a1ef125a

Available with next release.

Is it possible to add all upstream committers since last success to this Provider?

I think that would be a new provider

I agree this sounds like a new provider something like "UpstreamComitterSinceLastSuccess"

Thanks. Can anyone help with adding it? We are stuck with using the blame subversion plugin but would like to have a better solution.

Please file a new issue

Done https://issues.jenkins-ci.org/browse/JENKINS-34839 Thank you.