|
||||||||
|
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 |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
That is more-or-less how I envisioned the tool working actually.
Just to be clear, here is the rationale behind that particular need. In our case we have numerous interdependent 'modules' in our codebase, which have been mapped onto jobs in Jenkins. Further, the 'unit' tests associated with some of these modules require a significant amount of time to run. So in an effort to improve turnaround time on our farm we try to run unit tests for modules in parallel to compilation processes. This is probably best explained with an example:
Suppose Module B depends on Module A, and each one has a compile phase and test phase. Further, suppose each phase takes 5 minutes to complete. If run in sequence - module A build, module A test, module B build, module B test - we'd require 20 minutes for full completion. However, seeing as how module B build really only depends on module A being built we can run module A's tests at the same time, so now we get - module A builds, module A tests and module B builds both run in parallel, module B tests are then run after module B finishes compiling. In this scenario the full time to completion is reduced to 15 minutes. These benefits are even more noticeable in those cases when the 'unit' tests for a module take significantly longer to complete than the average compilation time.
When scaled across 20+ interdependent modules this strategy reduced our total build time for a complete end-to-end build from 10+ hours to 3 or less.