HI Erwan, The reason I have split up the build job into several logical ones is purely pragmatism...
When I do everything in one job and it fails I need to go through al lot of pages (I pasted every output per job into a word document and got about 1150 pages of output) to assess where the cause comes from. So based on experience I grouped it logically (in my opinion) based on my expectations of failure: 1. svn up, which should never fail unless svn cannot be connected. But when it fails, I don't need to run build, etc 2. clean, build and load demo - should never fail, unless something in the either my setup of Jenkins is wrong or in OFBiz applications. But when it fails, I don't need to run tests... 3. Run tests - If test fail then that is ok. I expect tests to go wrong. But if the process fails as a result of either Jenkins or OFBiz, then I want to know it as well. And it fails now due to misconfiguration of OFBiz as well... 4. Code coverage analysis and reporting - should never fail, unless something in the setup of Jenkins is wrong or in OFBiz (as it is now) I will look into the plugins, thanks. Regards, Pierre Op 9 april 2012 17:32 schreef Erwan de FERRIERES < [email protected]> het volgende: > Le 08/04/2012 16:30, Pierre Smits a écrit : > >> Hi Erwan, all, >> >> I have currently setup a test environment for continuous integration with >> Jenkins wereby I have following build/test setup configured: >> >> 1. pull from svn trunk the latest code (works perfectly - triggers 2) >> 2. Do ant targets "clean-all", "build" and "load-demo" (works perfectly >> - triggers 3) >> 3. Do ant targets "download-cobertura" and "download-sonar-ant-task" >> >> (works perfectly - for later cobertura code analysis and reporting to >> the >> sonar instance - triggers 4) >> 4. Do ant target "run-tests" (fails - see below - triggers 5 even when >> fails) >> 5. Do ant target "cobertura-report-xml" (works perfectly triggers 6, >> >> when I have figured out howto) >> 6. Do ant target "sonar" (not configured yet) >> >> >> First of all what do you think of that approach? >> > > Hi Pierre, > > you can reduce a lot the number of steps, and put all of them in only one > task. Is there a reason for having so much jobs ? > > 1 task: svn up + download-cobertura + download-sonar-ant-tasks + full-sonar > > You should install some plugins in Jenkins, like cobertura, junit and > sonar, and configure them. > In runtime/tests, you have the xml result from the junit tests, same for > cobertura. This would display directly historical data. > The sonar plugin (if I remember well) will just put a link to the sonar > project. > > > >> Secondly, >> Item # 4 fails on: >> >> 1. not having ports for testing set right. See JIRA issue >> 4794<https://issues.apache.**org/jira/browse/OFBIZ-4794<https://issues.apache.org/jira/browse/OFBIZ-4794> >> >, >> >> which I have fixed locally >> 2. not having a working build setting in framework/base/build.xml. See >> JIRA issue >> 4757<https://issues.apache.**org/jira/browse/OFBIZ-4757<https://issues.apache.org/jira/browse/OFBIZ-4757> >> > >> 3. on various test as it performs all unit tests available. >> >> >> The output generated is extensive and overwhelming. >> >> The question here is whether there is a list of all unit tests per >> component and/or test suites per component so that I can do a more >> granular >> testing per component and see what specific component test fails and what >> goes well. >> > look at the xml file I spoke about above. There is also an HTML report > generated. > > cheers, > > -- > Erwan de FERRIERES > www.nereide.biz >
