karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Further itest speed improvements
Date Sun, 27 Oct 2013 12:48:20 GMT
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é <jb@nanthrax.net>

> 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é
> jbonofre@apache.org
> 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/>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message