Hi, Let me explain it explain it more. There is one 'build scenario parametrized job: S(c); There are 3 matrix jobs: M1: with the axis c=C1, C2, C3. M2: c=C1, C3. M3: c=C2, C3.
Cause *I would like to avoid copying the S job* each matrix is configured to run S with the parameter that points the actual configuration. I.e: M1 runs: - M1 parent (and it is the fly-weight task by default), which runs: - M1(c=C1) runs (and do nothing else, therefore I'd like this to be fly-weight too): - S(c=C1) - this is the actual execution. - M1(c=C2) runs (and do nothing else, therefore I'd like this to be fly-weight too): - S(c=C2) - this is the actual execution. - M1(c=C3) runs (and do nothing else, therefore I'd like this to be fly-weight too): - S(c=C3) - this is the actual execution. M2 runs: - M2 parent (and it is the fly-weight task by default), which runs: - M2(c=C1) runs (and do nothing else, therefore I'd like this to be fly-weight too): - S(c=C1) - this is the actual execution. - M2(c=C2) runs (and do nothing else, therefore I'd like this to be fly-weight too): - S(c=C2) - this is the actual execution. M3 runs: - M3 parent (and it is the fly-weight task by default), which runs: - M3(c=C2) runs (and do nothing else, therefore I'd like this to be fly-weight too): - S(c=C2) - this is the actual execution. - M3(c=C3) runs (and do nothing else, therefore I'd like this to be fly-weight too): - S(c=C3) - this is the actual execution. S needs to be configured to let concurrent builds. M... children (i.e. the matrix job for each configuration - M...(c=...)) just triggers the S job passing the actual configuration to it and waits for the result. Therefore I would like this waiting not to consume the jenkins-configured executor (thus I understand that it will consume a little from real resurorces of one of the slaves). 2012/6/18 Simon Wiest <simon.wi...@web.de> > Hi Sebastian, > > the 'parent' matrix builds are always fly-weight tasks. So you do not need > to configure that explicitly. Only the individual 'child' matrix runs spawn > by the matrix build (in your example: C1, C2, C2, ...) will take up an > executor. > > By the way: matrix runs are executed in parallel by default. You would > have to check the "Run each configuration sequentially" option explicitly > to switch that off. > > Do you experience any specific problem with your current setup? > > Cheers, > Simon. > -- > Sebastian Sawicki (18.06.2012 02:11): > > Hi, >> I've got one build scenario (Scenario) which can be run by several >> configurations: >> Scenario(Configuration c) where c=C1, C2, C3,... >> >> The matrix build would fit here, cause I can set the configuration axes >> to cover each Configuration. >> However, what I need is to build some subset of those configurations in >> a few different matrixes i.e.: >> M1: C1, C2, C3. >> M2: C1, C3. >> M3: C2, C3. >> >> Therefore I thought about setting the Scenario as a parametrized job >> (where the current configuration will be set in the parameters) with the >> option set to enable concurrent builds. And then to launch this job with >> the given parameters from the matrix child build. >> As I understand this approach will consume 2 executors for each running >> configuration build (one for the matrix and second for the actual >> Scenario) although the matrix build will not do anything but waiting for >> the Scenario to complete and then just archive its artifacts. >> >> So here comes my question: If there is a possibility to set this whole >> matrix to act as flyweight task (and not to consume any >> jenkins-configured executor), since the job is done only by the Scenario >> and the matrix is intended just to choose which configurations would run? >> > > >