|
||||||||
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
[JIRA] (JENKINS-8597) Deal with matrix builds better
sven.appenr...@iav.de (JIRA) Fri, 25 Jan 2013 06:19:00 -0800
- [JIRA] (JENKINS-8597) Deal with matrix builds... sven.appenr...@iav.de (JIRA)
- [JIRA] (JENKINS-8597) Deal with matrix b... sven.appenr...@iav.de (JIRA)
- [JIRA] (JENKINS-8597) Deal with matrix b... sven.appenr...@iav.de (JIRA)
- [JIRA] (JENKINS-8597) Deal with matrix b... sven.appenr...@iav.de (JIRA)
- [JIRA] (JENKINS-8597) Deal with matrix b... sven.appenr...@iav.de (JIRA)
- [JIRA] (JENKINS-8597) Deal with matrix b... sven.appenr...@iav.de (JIRA)
- [JIRA] (JENKINS-8597) Deal with matrix b... sven.appenr...@iav.de (JIRA)
I agree. Nice idea to sort the prio of jobs but we're handling with many axis-jobs which can run on a slave too, so reducing their prio will improve our builds because the slave will be used better. My Test:
Job1(100) triggers Job2
Job2(xx) is Matrix with 20 axises doing sleep for a minute+-some random seconds each
Job3(100) triggers Job2 too
Result: even if Job2 has prio 50 or 150, Job 3 is the last one in the build queue.
Expected: after the first axis-job has finished, lauch Job3 instead of the next axis-job.
Edit:
OK - patching the config.xml in each subconfiguration is working but just a workaround...