Skip to content

[JENKINS-3607] Matrix project loses upstream when config saved #360

Closed
Bug
Closed
[JENKINS-3607] Matrix project loses upstream when config saved#360
Bug
Labels
component:matrix-project-pluginimported-jira-issuepriority:criticalresolution:fixed

Description

@jenkins-infra-bot
jenkins-infra-bot
opened on Apr 30, 2009

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.

Originally reported by acjohnso25, imported from: Matrix project loses upstream when config saved
  • assignee: mindless
  • status: Closed
  • priority: Critical
  • component(s): matrix-project-plugin
  • resolution: Fixed
  • resolved: 2009-10-26T09:27:54+00:00
  • votes: 0
  • watchers: 1
  • imported: 2025-12-06
Raw content of original issue 
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.
  • environment: Platform: Other, OS: Linux

Activity

  1. jenkins-infra-bot commented on Apr 30, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Apr 30, 2009
    Author
    mdonohue:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
      This sounds awfully similar to issue 3284

    This sounds awfully similar to issue 3284

  2. jenkins-infra-bot commented on May 1, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 1, 2009
    Author
    acjohnso25:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
      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.

    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.

  3. jenkins-infra-bot commented on May 1, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on May 1, 2009
    Author
    acjohnso25:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
      Oh, and forgot to mention:  I'm not experiencing issue 3284 here.

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

  4. jenkins-infra-bot commented on Jul 9, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Jul 9, 2009
    Author
    mdonohue:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
        
	
      • 
	
          
		
        • 
		
            
			
          • Issue 4004 has been marked as a duplicate of this issue. ***
            • 
		
          
		
          • 
	
        
	
        •
        • Issue 4004 has been marked as a duplicate of this issue. ***

  5. jenkins-infra-bot commented on Aug 25, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Aug 25, 2009
    Author
    jking_ok:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
      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.

    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.

  6. jenkins-infra-bot commented on Oct 1, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Oct 1, 2009
    Author
    mdonohue:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
        
	
      • 
	
          
		
        • 
		
            
			
          • Issue 4551 has been marked as a duplicate of this issue. ***
            • 
		
          
		
          • 
	
        
	
        •
        • Issue 4551 has been marked as a duplicate of this issue. ***

  7. jenkins-infra-bot commented on Oct 6, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Oct 6, 2009
    Author
    mdonohue:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
        
	
      • 
	
          
		
        • 
		
            
			
          • Issue 4598 has been marked as a duplicate of this issue. ***
            • 
		
          
		
          • 
	
        
	
        •
        • Issue 4598 has been marked as a duplicate of this issue. ***

  8. jenkins-infra-bot commented on Oct 26, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Oct 26, 2009
    Author
    mdonohue:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
        
	
      • 
	
          
		
        • 
		
            
			
          • Issue 4703 has been marked as a duplicate of this issue. ***
            • 
		
          
		
          • 
	
        
	
        •
        • Issue 4703 has been marked as a duplicate of this issue. ***

  9. jenkins-infra-bot commented on Oct 26, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Oct 26, 2009
    Author
    mindless:

    Started.

  10. jenkins-infra-bot commented on Oct 26, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Oct 26, 2009
    Author
    wohauser:

    put me on cc

  11. jenkins-infra-bot commented on Oct 26, 2009

    @jenkins-infra-bot
    jenkins-infra-bot
    on Oct 26, 2009
    Author
    scm_issue_link:
    • Comment link
    • Original comment link (no redirect)
    • Raw content of original comment: 
      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)

    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)

  12. jenkins-infra-bot
    closed this as completedon Oct 26, 2009
  13. jenkins-infra-bot
    added
    bug
    imported-jira-issue
    on Dec 6, 2025

  14. jenkins-infra-bot commented on Dec 6, 2025

    @jenkins-infra-bot
    jenkins-infra-bot
    on Dec 6, 2025
    Author

    [Original is_duplicated_by from Jira: JENKINS-4004]

  15. jenkins-infra-bot commented on Dec 6, 2025

    @jenkins-infra-bot
    jenkins-infra-bot
    on Dec 6, 2025
    Author

    [Original is_duplicated_by from Jira: JENKINS-4551]

  16. jenkins-infra-bot commented on Dec 6, 2025

    @jenkins-infra-bot
    jenkins-infra-bot
    on Dec 6, 2025
    Author

    [Original is_duplicated_by from Jira: JENKINS-4598]

  17. jenkins-infra-bot commented on Dec 6, 2025

    @jenkins-infra-bot
    jenkins-infra-bot
    on Dec 6, 2025
    Author

    [Original is_duplicated_by from Jira: JENKINS-4703]

  18. jenkins-infra-bot
    added
    component:matrix-project-plugin
    resolution:fixed
    priority:critical
    on Dec 6, 2025
  19. jenkins-infra-bot
    added the
    Bug
    issue type on Dec 6, 2025
  20. jenkins-infra-bot
    removed
    bug
    on Dec 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    component:matrix-project-pluginimported-jira-issuepriority:criticalresolution:fixed

    Type

    Bug

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions