-
New Feature
-
Resolution: Fixed
-
Critical
-
None
It would be extremely useful to be able to throttle the number of concurrent builds of matrix configurations that can take place on a given node. The reason for this is when you have a matrix project in which all subprojects share the same parent workspace data. It is possible then to run concurrent builds across separate nodes, but not on the same node.
The specific use case I am running into is for building Android. I have a matrix project that defines configurations for each device I wish to build. Every sub-project shares the same android source tree to build off of, so concurrent builds are not possible on the same node as they would clobber each other, but concurrent builds on separate nodes would be fine.
- is duplicated by
-
JENKINS-16521 Multi-Project Throttle Categories don't work with Matrix jobs
-
- Resolved
-
-
JENKINS-19986 Throttle Concurrent Builds plugin doesn't appear to work
-
- Resolved
-
-
JENKINS-20574 throttling needs to account for all child jobs of a multiconfiguration job
-
- Resolved
-
- is related to
-
JENKINS-19986 Throttle Concurrent Builds plugin doesn't appear to work
-
- Resolved
-
-
JENKINS-23902 Matrix parent takes executor slot and blocks children
-
- Closed
-
-
JENKINS-23439 Configurable bahavior on matrix build job
-
- Resolved
-
We are using Jenkins to test code running on embedded devices.
We have multiple nodes in our setup, each one has only one (1) embedded device attached to it.
We have two types of Jobs:
When tests are running on an embedded device (Job type 1), the node's CPU is mostly free. However, we cannot take advantage of this free CPU to run type 2 jobs because we can only have one executor per node.
We cannot have more then one executor per node because we don't have the "ability to throttle number of concurrent builds of matrix configurations per node" for type 1 jobs.
We need the "ability to throttle number of concurrent builds of matrix configurations per node" so that different configurations of a type 1 Job are not concurrently run on one node as each node only has one embedded device.
This would improvement would greatly increase the effectiveness of our continuous integration setup.