Hi guys, I'm with ya' that a nightly with deploy should be sufficient. Regarding the PerSuite / other Speed enhancements I'm not against but we'd need to be very cautions that we don't have side-effects of this. That's why I usually prefer to have the perTest fork and/or annotation on the UnitTests. It just makes sure you work on a clean container (just like you would work on a clean database ;) ) I think at that point we just need to "bite that bullet" and keep to those longer running tests.
regards, Achim 2013/10/27 Jean-Baptiste Onofré <[email protected]> > Hi Christian, > > It's what I said in my previous e-mail: if possible, I would like to avoid > a job dedicated to itests. If there are no other ways, we will do like this. > > For the PerSuite, you have an option in Pax Exam to reuse an existing > container. Let me try with that. > > Regards > JB > > > On 10/27/2013 10:35 AM, Christian Schneider wrote: > >> Hi JB, >> >> I created an itest build here: >> https://builds.apache.org/**view/H-L/view/Karaf/job/Karaf-**itests/<https://builds.apache.org/view/H-L/view/Karaf/job/Karaf-itests/> >> >> You can reuse it or delete it when you create a new build. >> >> About the PerSuite tests. I have experimented a bit. In eclipse I was >> able to run most of the karaf tests successfully in PerSuite mode and >> they are really extremely fast. Unfortunately I was not able to make >> them work with maven. In maven the karaf container was always created >> for each test class. I think it is related to the fork mode of surefire. >> By default it seems to start a fresh process for each test class. When I >> changed forkCount to 0 none of the tests work. So the results of my >> experiments is that it has a lot of potential but currently does not >> work correctly. >> >> Christian >> >> Am 27.10.2013 07:49, schrieb Jean-Baptiste Onofré: >> >>> Hi Christian, >>> >>> On 10/26/2013 09:28 PM, Christian Schneider wrote: >>> >>>> On 26.10.2013 21:14, Jean-Baptiste Onofré wrote: >>>> >>>>> Hi Christian, >>>>> >>>>> - If you mean create two job in Jenkins, I disagree. I would prefer to >>>>> work with profiles. More over, it makes sense to tight the itest on >>>>> the artifacts that we just built before. Maybe we can have to target >>>>> on Jenkins: one with the itest profile, one without the itest profile. >>>>> The trigger for the full build (including itest) is every night, the >>>>> build without itest is at scm polling. >>>>> >>>> I did not want to have a build without itests. The itests are fast >>>> enough to run in both builds. I wanted one build with itests after each >>>> commit and one build with itests and deploy nightly. The problem >>>> currently seems to be the deploy it takes much longer than the tests. >>>> >>> Catcha, so build without deploy after scm poll, and deploy only for >>> nightly builds ? I can do that. >>> >>> - For the PerClass test on feature, I'm agree. >>>>> - Not sure I follow you for the PerSuite. What do you mean ? >>>>> >>>> PerSuite will start karaf only once and run several test classes on it. >>>> >>> Catcha, you mean reuse the same Karaf container for all itests. We >>> just have to be careful that one itest doesn't impact another. I have >>> issues like this when I implemented itests. >>> >>> Regards >>> JB >>> >>> >>>> Christian >>>> >>>> >>> >> >> > -- > Jean-Baptiste Onofré > [email protected] > http://blog.nanthrax.net > Talend - http://www.talend.com > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
