Status: Closed (View Workflow)
Platform: Other, OS: Linux
Attempting to set two multi-configuration projects in sequence is problematic.
Steps to reproduce:
Create two multi-configuration projects (e.g. "foo" and "bar"), and configure
each one to build on two (or more) nodes. Go into bar's configuration and
attempt to put foo upstream (i.e. put "foo" in "Build after other projects are
built"). Save the configuration. Observe that the change did not take; bar has
no upstream projects.
Now, go into foo's configuration and put bar downstream (i.e. put "bar" in
"Build other projects"). Save the configuration. (This part works.) Go into
bar's configuration again, and note that "Build after other projects are built"
correctly lists "foo". Don't change anything, just save the configuration.
Observe that bar has no upstream projects again.
Two symptoms, but they definitely appear to be the same issue. The first one is
easier to work around, the second one is more of a pain. I first observed this
with (I think) v1.289, but I can't say for sure that's when it appeared. It's
still an issue as of v1.300.
- is duplicated by
JENKINS-4004 Updating configuration of multi-configuration jobs causes dependency loss
JENKINS-4551 multi-configuration project is loosing its dependencies
JENKINS-4598 Dependency configuration between matrix projects not working properly
JENKINS-4703 Upstream projects always deleted while saving job configuration
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.
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
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
2. Only modify the build triggers on Configurable Projects. (Referring to 1.321
source) wrap lines 494-538 with
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,
Hope this helps out - Joshua.
Code changed in hudson
User: : mindless
[FIXED JENKINS-3607] Omit unconfigurable project types (like MatrixConfiguration)
from upstreamProject processing (suggested by jking_ok)
This sounds awfully similar to issue 3284