Hey Chris, I agree that the Matrix jobs could do with some work, for instance I find I keep getting confused between the Master and Child elvels when looking for execution output (as they look the same, but you need to go through on to get to the other). Also they could make it more clear what sections will be executed on the Child and which on the master job (and make this more configurable - as there are some things you cannot do with matrix jobs that you can do with normal jobs).
However I'm not sure I described our issues properly. Whilst the below is true: > > We found that this worked at the child level, > > I think that's what you want though... Each point in the matrix is a > child, and it's each child that you want to lock resources, right? > You wan the children to run in parallel to speed things up, but not > trample on each other, right? > The Throttle Concurrent job plug in only allows you to specify labels which will affect all the child jobs. For example if we specified we wanted to throttle Gen 1, Gen 2 and Gen 3 to one Executor each. Then if we told a Matrix job to use the Throttle concurrent categories Gen1, Gen2 and Gen3, each child would say it's using Gen 1 Gen 2 and Gen 3 - which would in affect make them run serially. What in fact we want is one child job working on Gen 1, one on Gen2 and one on Gen 3 (so they could all run in parallel - provided the Slave has 3 executors). This is why we thought of adding a new axis as this seems to be the only way to give Child jobs of a Matrix job different arguments. Regards, Tim -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
