This sounds awfully similar to issue 3284

Yes, I noticed that one, but the description (assuming it's accurate) didn't
capture what I'm seeing. There, the configuration page is not loading with the
correct upstream project. Here, the configuration page is not saving it, and
it's only an issue with multi-config projects.

Could very well be the same root cause, though.

Oh, and forgot to mention: I'm not experiencing issue 3284 here.

• • • Issue 4004 has been marked as a duplicate of this issue. ***

Okay I spent some time on this because it bugged me and debugging it shows that
the issue is triggered in the hudson.model.AbstractProject.doConfigSubmit
method. This gets triggered by the Save button on a Configure page.

In doConfigSubmit, a parameter called "pseudoUpstreamTrigger" is set when there
was a build trigger specified in the request (either because the user added
one - case #1, or because a dependency already existed and the user didn't
remove it - case #2). In doConfigSubmit this parameter is a trigger to generate
a list of upstream projects from the names specified, or if not set, the list
of upstreams remains empty. The method then updates for all of the projects in
Hudson to match the state of the upstream project list.

This works fine for freestyle projects (hudson.model.FreeStyleProject) but
doesn't work for multi-configuration projects (hudson.matrix.MatrixProject)
because it turns out that each configuration
(hudson.matrix.MatrixConfiguration) is also a Project, with the settings fields
within the configuration referring back to the parent multi-configuration
project.

The problem there is each configuration has a unique name and doConfigSubmit
uses the names to determine whether a project is upstream. However the names it
uses are the human-friendly names and only match the MatrixProject instances.
Thus every time a MatrixConfiguration instance is encountered, doConfigSubmit
asks the MatrixConfiguration to remove its build trigger, which has the effect
of removing the build trigger on the MatrixProject itself because a reference
to its build trigger is returned by the MatrixConfiguration.

I have two solutions to the issue for the developer(s) to consider:
1. Instead of testing against the display name of the Project to determine if a
project is an upstream one, test against the name of the Project's root. This
is in the AbstractProject methods. ie, (referring to 1.321 source) change
hudson.model.AbstractProject line 494 to:
boolean isUpstream = upstream.contains(p.getRootProject());

This works because all MatrixConfigurations are sub-projects of the
MatrixProject and thus the test will return the correct result for each
configuration of a MatrixProject. It will however update the list redundantly
for each configuration (only needs to be done once on the MatrixProject
itself). This change works for me, I am using it in a custom build of Hudson
now.
2. Only modify the build triggers on Configurable Projects. (Referring to 1.321
source) wrap lines 494-538 with
if (p.isConfigurable())

This should work because MatrixConfigurations all redefine isConfigurable (by
default true) to false. This would remove the redundant updating of fix 1 and I
haven't tested this one yet.

Note that I've tested against freestyle and multi-configuration projects - I
don't have any of the other Project types in use yet to test against (maven2,
external monitor).

Hope this helps out - Joshua.

• • • Issue 4551 has been marked as a duplicate of this issue. ***

• • • Issue 4598 has been marked as a duplicate of this issue. ***

• • • Issue 4703 has been marked as a duplicate of this issue. ***

Started.

put me on cc

Code changed in hudson
User: : mindless
Path:
trunk/hudson/main/core/src/main/java/hudson/model/AbstractProject.java
trunk/www/changelog.html
http://fisheye4.cenqua.com/changelog/hudson/?cs=23207
Log:
[FIXED JENKINS-3607] Omit unconfigurable project types (like MatrixConfiguration)
from upstreamProject processing (suggested by jking_ok)