Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-3607

Matrix project loses upstream when config saved

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • matrix-project-plugin
    • None
    • 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.

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

          acjohnso25 added a 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.

          acjohnso25 added a 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.

          acjohnso25 added a comment -

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

          acjohnso25 added a comment - Oh, and forgot to mention: I'm not experiencing issue 3284 here.

          mdonohue added a comment -
              • Issue 4004 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 4004 has been marked as a duplicate of this issue. ***

          jking_ok added a 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.

          jking_ok added a 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.

          mdonohue added a comment -
              • Issue 4551 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 4551 has been marked as a duplicate of this issue. ***

          mdonohue added a comment -
              • Issue 4598 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 4598 has been marked as a duplicate of this issue. ***

          mdonohue added a comment -
              • Issue 4703 has been marked as a duplicate of this issue. ***

          mdonohue added a comment - Issue 4703 has been marked as a duplicate of this issue. ***

          Alan Harder added a comment -

          Started.

          Alan Harder added a comment - Started.

          wohauser added a comment -

          put me on cc

          wohauser added a comment - 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)

          SCM/JIRA link daemon added a 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)

            mindless Alan Harder
            acjohnso25 acjohnso25
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: