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?
>>
>
>
>

Reply via email to