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

Matrix Reloaded should trigger the same combination in downstream matrix job

    XMLWordPrintable

Details

    Description

      When rebuilding parts of a matrix job (using the matrix reloaded plugin), the build will then trigger all downstream jobs. In our case, the downstream jobs are also matrix jobs and we would like that in this case, the downstream jobs are also "reloaded", i.e. only the parts that were rebuilt in the upstream job should be built there as well.

      To reproduce, I've used a setup that somewhat resembles what we have:

      • 2 matrix jobs, jobA and jobB
      • jobA has jobB as its downstream job
      • each job consists of a 3x3 matrix with the axis labelled "compiler" and "os" respectively
      • the compiler axis has values FORTE, GCC, MSC
      • the os axis has values solaris, linux, windows
      • the build step is just a echo "hello world"

      We're using the Parameterized Build plugin, http://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin, to trigger downstream builds but this can also be reproduced with the standard "Build other projects" option.

      The two screenshots show the matrix and which parts are supposed to be rebuild. The second screenshot shows that jobB, when triggered by rebuilding only parts of the jobA matrix, is actually building all 9 combinations, not just the 2 of the upstream job.

      P.S. I mentioned this problem at the Jenkins User Conference in Paris, in case you remember

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          lars_kruse Lars Kruse added a comment - - edited

          I got it! I think.

          Please confirm that this is what you want:

          When Matrix reloaded Plugin is installed:
          IF a Matrix Build is a down-stream job of another job
          AND the upstream job also is a Matrix build
          AND the upstream job is started by the Matrix Reloaded Plugin
          AND the axises of the upstream build and this have a "perfect match" (both axises and the values are exactly the same)
          THEN this build should also be a Matrix Reloaded build, rebuilding with the same settings as the upstream build did.

          We have set up a test bed that resembles your secretion above, this is where we plan to prove the feature done.
          http://code.praqma.net/ci/view/JENKINS-13514/

          lars_kruse Lars Kruse added a comment - - edited I got it! I think. Please confirm that this is what you want: When Matrix reloaded Plugin is installed: IF a Matrix Build is a down-stream job of another job AND the upstream job also is a Matrix build AND the upstream job is started by the Matrix Reloaded Plugin AND the axises of the upstream build and this have a "perfect match" (both axises and the values are exactly the same) THEN this build should also be a Matrix Reloaded build, rebuilding with the same settings as the upstream build did. We have set up a test bed that resembles your secretion above, this is where we plan to prove the feature done. http://code.praqma.net/ci/view/JENKINS-13514/
          dhaun Dirk Haun added a comment - - edited

          Thanks for looking into this.

          There's one detail I left out of the original description: Not all our downstream matrix jobs have exactly the same two axis. We have a few base libraries that need to be built for all combinations of platforms but further down the tree, we have products that are built on fewer platforms.

          For example, we have products that are Windows-only (due to ties with the Windows API). So if, say, the build for the base library for Windows failed, we would still like to be able to re-trigger that build and also the Windows-only builds further down the tree.

          So I'd like to rephrase the "perfect match" requirement to something like "If the downstream matrix has any of the selected combinations, then build those that are available."

          In other words, we may have cases where we trigger, say, Solaris and Windows builds at the top, but further down the tree, there are Matrix jobs without the Solaris option, but we would still like it to trigger the Windows option in that Matrix (obviously, any downstream jobs from those matrix jobs then won't have a Solaris option either).

          Does that make sense?

          dhaun Dirk Haun added a comment - - edited Thanks for looking into this. There's one detail I left out of the original description: Not all our downstream matrix jobs have exactly the same two axis. We have a few base libraries that need to be built for all combinations of platforms but further down the tree, we have products that are built on fewer platforms. For example, we have products that are Windows-only (due to ties with the Windows API). So if, say, the build for the base library for Windows failed, we would still like to be able to re-trigger that build and also the Windows-only builds further down the tree. So I'd like to rephrase the "perfect match" requirement to something like "If the downstream matrix has any of the selected combinations, then build those that are available." In other words, we may have cases where we trigger, say, Solaris and Windows builds at the top, but further down the tree, there are Matrix jobs without the Solaris option, but we would still like it to trigger the Windows option in that Matrix (obviously, any downstream jobs from those matrix jobs then won't have a Solaris option either). Does that make sense?
          lars_kruse Lars Kruse added a comment -

          Right - I makes sense.

          What we'll do is that we will not require the axises and their values to be a "perfect match" but instead we will simply analyze which one of the reloaded combinations that makes sense in the context of the down-stream build - the ones that do will be reloaded, the rest will be ignored.

          If nothing makes sense - nothing will be build.

          The consequence of this is that a reloaded up-stream build could trigger a down-stream build, that potentially does nothing at all. This may be right in your context, but it's different from the way the plugin behaves today, and in order to make the behavior backwards compliant we intend to set a checkbox on the reloaded plugin, marking if down-stream builds should run in reloaded "mode" too - or not.

          Based on this revised design I'd like to raise the estimate with 4 hrs to a total of 20 hrs all in all - including 12 month support of this new feature.

          What do you think?

          lars_kruse Lars Kruse added a comment - Right - I makes sense. What we'll do is that we will not require the axises and their values to be a "perfect match" but instead we will simply analyze which one of the reloaded combinations that makes sense in the context of the down-stream build - the ones that do will be reloaded, the rest will be ignored. If nothing makes sense - nothing will be build. The consequence of this is that a reloaded up-stream build could trigger a down-stream build, that potentially does nothing at all. This may be right in your context, but it's different from the way the plugin behaves today, and in order to make the behavior backwards compliant we intend to set a checkbox on the reloaded plugin, marking if down-stream builds should run in reloaded "mode" too - or not. Based on this revised design I'd like to raise the estimate with 4 hrs to a total of 20 hrs all in all - including 12 month support of this new feature. What do you think?

          People

            wolfgang Christian Wolfgang
            dhaun Dirk Haun
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: