|
||||||||
|
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, the rationale for that particular requirement is caused by the size of our codebase and the sheer time required to build and test all interdependent modules. For example, we have 20+ interdependent modules in our codebase, each of which requiring its own separate compile and test phase. In many cases the test phases take much longer to complete than the compilation phase so we tend to try avoiding execution of unit tests when they are not necessary. We do this currently by only running tests when a compile is performed, and compiles are only performed when there are commits to a module or one of its dependencies.
So, if Module B depends on Module A and someone commits a change to Module A we want to build and test Module A then Module B. However, if a change is made only to Module B we don't want to re-build or re-test Module A. We manage this at the moment using commit triggers in Jenkins. When changes are made to Module B we only trigger Module B's compile and test, which will then in turn trigger any downstream modules that depend on it.
To give more practical results for reference, consider you have 26 modules dependent on one another, Modules A-Z. Further, suppose each module has an associated test phase that requires 5 minutes to complete. If someone commits a change to Module Z and all modules in the pipeline get rebuilt and tested, even if the build/rebuild process for each is instant - which typically they aren't - it will still require 2h+ to run through the pipeline. However, if we can only rebuild and retest Module Z we can complete the process in 5 minutes (plus the time to recompile of course) which provides significantly faster feedback to developers.
Granted our particular needs are somewhat exacerbated by the sheer size of our codebase, I would be surprised if even smaller shops wouldn't see an obvious benefit to this. Even if you only have 2 or 3 interdependent modules that exhibit the same behavior you would see noticeable improvements in turnaround time.