Hi, Am 17.11.2015 um 15:14 schrieb John Mellor:
>> Typically I don't declare any job dependencies there. Each project can be >> built and tested on its own, and the projects using the libraries would use >> the results from the last successful build, so you still get the maximum >> coverage if a library breaks. > I strongly disagree. Always specify the compile-time dependencies. I assume > that you are not just cherry-picking product versions that happen to mostly > work, and actually need the work that is current to be the UUT. The library > that you just built should be the one you test with, not some old version. > Testing old libraries that are not going to be shipped may occasionally get > you nice coverage numbers, but so what? It not representative of the work > just done. My point is that if a library fails to compile, that should not stop the dependent projects from getting any work done, and it should not show up as build failures for them. Jenkins keeps track of dependent libraries pulled in as artifacts, so simply triggering a rebuild of dependent projects after a library changed is a good way to get the latest version of the library fully tested (and failures show up with an empty project changelog and a note that it was an artifact change that led to the failure). However a "build library projects first" dependency is too strong. Simon -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/564B3AAC.7050603%40hogyros.de. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
