Child pages
  • Blame Upstream Committers Plugin

Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

No information for the plugin 'blame-upstream-commiters' is available. It may have been removed from distribution.

This is a simple plugin that adds a post build action to mail upstream committers when a build fails. This plugin is useful when you have a downstream job that uses an artifact produced by an upstream build.

Once you install the plugin, ensure that it is properly installed by looking at the bottom of the job's configuration page, where the following checkbox should be available:

 Mail upstream committers when the build fails

It is important to notice that:

  • Only builds that are actually triggered by an upstream build will actually send the mail
  • If the upstream job did not include any SCM update at all, it won't trigger the mail (as expected)

Jobs Setup

This plugin is only capable of blaming upstream committers if the job is linked by some dependency to the upstream job. The relation is created using fingerprints. Look how to fingerprint here or just follow the steps below for a quick start.

1. Create the upstream/downstream relationship by setting editing the downstream job and entering information in the following field:

  Build after other projects are built

Enter the upstream project name in the input box. It is also possible to create the same relationship by editing the upstream job configuration

  Build other projects

Both method will work for our purposes

This plugin works when the downstream job uses an artifact produced by the upstream job. To create such relationship you'll need to setup the downstream job in such a way that it fetchs the upstream's produced artifact and this artifact must be fingerprinted in both jobs. Let's see how to do that:

2.1 Fingerprint the artifact to be used in the upstream job

In the Post-build Actions section, you'l find the following option:

  Record fingerprints of files to track usage

When this option is checked, a "Files to fingerprint" input box will become avaiable. You can specify the file explicitly or using wildcards. Just make sure the file to be used by the downstream job is fingerprinted.

Notice that if this is a Maven project, this option will not be available. In fact, maven jobs automatically fingerprints any produced jars that are archived.

2.2 Fetch the required artifact in the downstream job

You'll have to find a way to get the produced artifact. If both jobs are executed in the same computer, you can just copy the file from the workspace. This is not such a good option, since it forces both jobs workspaces to be in the same filesystem. A better option is to download the file somehow (for example, using wget or an ant task) from the upstream's urls.

2.3 Fingerprint the artifact in the downstream job

Finally, the downstream job must fingerprint the downloaded file. You'll use the same post-build action as in the upstream job.

2.4 Check the "Mail upstream committers when the job fails"

That's all you need to go.

Once you follow the above steps, the jobs will be properly linked and the upstream committers will be mailed when the downstream job fails.

Change Log

Version 1.2 (Sept 15, 2010)
  • Fixed a bug when an upstream project contained a space character in its name, see JENKINS-7322
Version 1.1 (Jan 21, 2010)
  • No functional change, just fixing plugin name/version
Version 1.0 (Oct 9, 2009)
  • Initial release


  1. Unknown User (jminne)

    I just wanted to note that there's also a core patch activated by -Dhudson.upstreamCulprits=true
    That option changes the meaning of the "Include Culprits" checkbox in the ext-email plugin.

    That's pretty nice since the emails get all the formatting magic from ext-mail.  And if a job does not want to include upstream committers you just do not check "Include Culprits".

    A related discussion:

  2. Unknown User (


    does it also work transitively?

    My scenario is a web application scenario and I use Selenium to automate UI tests.

    So the scenario is build(triggered by commit) -> deploy -> test

    If the test fails it is usually because "bad code" was committed, so in case the tests fail the committer has to be notified, but the commit did not happen in the direct upstream project.

    In a large application there might even be more steps inbetween.

    Currently I don't get this running.I get the following error in the console:


    Upstream projects changes detected. Mailing upstream committers in the following projects:
    Unable to compute the changesets in [hudson.model.FreeStyleProject@accd65[DEPLOY|mailto:hudson.model.FreeStyleProject@accd65DEPLOY]

    Also I don't understand why it says "Upstream projects changes detected"? Does changes refer to "SCM" change? But why then for the "DEPLOY" project, there was no SCM change in this (the DEPLOY project does not even have a SCM configured)?

    Best regards,


    1. Unknown User (


      I've just seen the mentioned discussion at

      is exactly about this functionality. So I could solve it by setting CATALINA_OPTS=-Dhudson.upstreamCulprits=true

      thanks and regards,