Status: Resolved (View Workflow)
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
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?
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?
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.