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