This is in the normal downstream configuration of Jenkins and not in the Downstream-Ext plugin. Therefore changing component to core

Re-save all job configurations involved and try again. This is likely caused by JENKINS-16956 in 1.560.

Hi, I can confirm that the problem happens in Jenkins 1.563 with three new jobs created from scratch. When in project B you choose "Build after other projects are built" you have "Trigger only if build is stable" selected by default. When you add as a post-build action "Build other projects", none of the previous radio buttons are selected (it seems almost a javascript problem).
If you save the configuration like that for the job B, and you run the job A, you'll get the error "java.lang.NullPointerException at hudson.model.Result.isBetterOrEqualTo(Result.java:125)" and job B will not be triggered.

Donato: Thanks for the explanation. I experience the same issue on 1.567.

Annoying workaround: Re-set the 'trigger after other projects' threshold after adding a 'build other projects' post-build step, and whenever opening the config form again if there's a 'build other projects' configured.

Hi Daniel, the workaround works, but you have to do that every time you modify the job (let me say, if you change the description, you will also have to set the radio button for the downstream project trigger). From my personal experience, it's very easy to forget it.

The NPE is just a side effect of the configuration form issue, which I can reproduce interactively but not in a test.

<input name="threshold" value="SUCCESS" type="radio" checked="true"> in the HTML, yet it is visibly unchecked in Chrome. I think this is due to there being another input of the same name and value elsewhere in the form. Perhaps HtmlUnit does not check that condition.

Code changed in jenkins
User: Jesse Glick
Path:
test/src/test/java/jenkins/triggers/ReverseBuildTriggerTest.java
http://jenkins-ci.org/commit/jenkins/e1e7f1b93b48998e1068275c6406335e7b7f364d
Log:
JENKINS-23191 Cannot reproduce problem in HtmlUnit test, but can at least guard against other regressions.

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
core/src/main/resources/hudson/tasks/BuildTrigger/config.jelly
core/src/main/resources/jenkins/triggers/ReverseBuildTrigger/config.jelly
core/src/main/resources/lib/form/radio.jelly
http://jenkins-ci.org/commit/jenkins/d660d60ea7e2e411972b215fc7f6fee9ff03e329
Log:
[FIXED JENKINS-23191] f:radio is not databinding-aware and does not correctly handle multiple configuration sections unless you make it.

Integrated in jenkins_main_trunk #3471
JENKINS-23191 Cannot reproduce problem in HtmlUnit test, but can at least guard against other regressions. (Revision e1e7f1b93b48998e1068275c6406335e7b7f364d)
[FIXED JENKINS-23191] f:radio is not databinding-aware and does not correctly handle multiple configuration sections unless you make it. (Revision d660d60ea7e2e411972b215fc7f6fee9ff03e329)

Result = SUCCESS
Jesse Glick : e1e7f1b93b48998e1068275c6406335e7b7f364d
Files :

• test/src/test/java/jenkins/triggers/ReverseBuildTriggerTest.java

Jesse Glick : d660d60ea7e2e411972b215fc7f6fee9ff03e329
Files :

• core/src/main/resources/hudson/tasks/BuildTrigger/config.jelly
• core/src/main/resources/lib/form/radio.jelly
• core/src/main/resources/jenkins/triggers/ReverseBuildTrigger/config.jelly
• changelog.html

It seems there is still a problem, don't know whether it is the same: Previously the "build after other project"-trigger was a mirror of the post-build-action "Build other project". Now, you can alter the "Build other project" (e.g. removing job C from PBA of job B) and the trigger in job C is not updated. On the other hand changes in trigger of job C are not reflected in job B anymore. Actually the settings in job C have no effect, ie. when no PBA is configured in B, job C is never triggered, whatever it's configuration is.

Christian: This is a deliberate, documented change. Quoting the changelog for 1.560:

The “upstream pseudo trigger” was also removed in favor of a true trigger configured on the downstream project; you may use either the post-build action or the trigger according to where you want this configuration stored, and who is authorized to change it.

Actually the settings in job C have no effect, ie. when no PBA is configured in B, job C is never triggered, whatever it's configuration is.

This could be a legitimate bug. Could you provide complete and detailed steps to reproduce this on a test instance with default plugins?

Seems to be a problem of the Maven-job:

Setup "job A" as Freestyle Project
Setup "job B" as Freestyle Project and set "job A" as trigger (Status shows job A as Upstream Project)

Setup "job Maven-B" as Maven Project and set "job A" as trigger (Status does not show any upstream project)

When "job A" is build and finishes, "job B" is triggered, but not "job Maven-B"

You can make "job Maven-B" triggered by "job A" by setting it as a Post-Build-Action in "job A"

Christian: Does this only affect Maven projects?

Daniel: At least Freestyle doesn't have this problem

Christian: Please file a new bug for the 'maven' and 'core' components with this description. Link it to this one as related (More Actions button).

Code changed in jenkins
User: Jesse Glick
Path:
test/src/test/java/jenkins/triggers/ReverseBuildTriggerTest.java
http://jenkins-ci.org/commit/jenkins/84195ea8468766df8df470f3a1a686caefb644a3
Log:
JENKINS-23191 Cannot reproduce problem in HtmlUnit test, but can at least guard against other regressions.
(cherry picked from commit e1e7f1b93b48998e1068275c6406335e7b7f364d)

Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/resources/hudson/tasks/BuildTrigger/config.jelly
core/src/main/resources/jenkins/triggers/ReverseBuildTrigger/config.jelly
core/src/main/resources/lib/form/radio.jelly
http://jenkins-ci.org/commit/jenkins/bd378a1ed2472dabab979ae727cb54459e098431
Log:
[FIXED JENKINS-23191] f:radio is not databinding-aware and does not correctly handle multiple configuration sections unless you make it.
(cherry picked from commit d660d60ea7e2e411972b215fc7f6fee9ff03e329)

Conflicts:
changelog.html

@christianlangmann file in maven component and link to JENKINS-16956 (probably not directly related to this bug).

@Jesse, @Daniel: Thanks for advice, bug created: JENKINS-23686