On Thu, Apr 23, 2015 at 8:29 PM, Oliver Lietz <[email protected]> wrote:
> On Thursday 23 April 2015 14:44:49 Bertrand Delacretaz wrote:
>> On Thu, Apr 23, 2015 at 1:51 PM, Oliver Lietz <[email protected]> wrote:
>> > ...Apart from that we can create a dedicated build job for Karaf
>> > Launchpad....
>>
>> That would be great as it looks like that would speed up the contrib
>> build job a lot.
>
> Yes, the 53 integration tests currently take 40 minutes when not failing and
> this is worth a dedicated build job.
>
> While we're at it... is there a build job for running Launchpad's integration
> tests?

We currently build and test the launchpad for each 'folder' - / and
/contrib  There's the sling-oak-it-1.7 job, but that's because we run
against Jackrabbit by default.

That being said, I was considering splitting our jobs a bit, so that
the integrations tests run after all modules are built and deployed,
e.g.

sling-trunk-1.7 ( mvn clean deploy # no IT )
\- sling-trunk-it-1.7 ( just ITs, Jackrabbit )
\- sling-trunk-oak-it-1.7 ( just ITs, Oak )

The 1.8 version would be the same, just that we would run mvn clean
install on sling-trunk-1.8, as we have already deployed the modules
previously . Hmmmm, maybe it makes sense to also trigger
sling-trunk-it-1.8 from sling-trunk-1.7, and leave sling-trunk-1.8 as
a simple mvn clean install to validate that the per-module tests run
with Java 8.

And then we can apply the same pattern to contrib

sling-contrib-1.7 ( mvn clean deploy, # no ITs )
\- sling-contrib-it-1.7
\- sling-contrib-karaf-1.7
\- sling-contrib-it-1.7

Thoughts?

Robert

>
> I still have failing tests when running Launchpad's integration tests against
> Karaf but I don't think Karaf is the cause (well, there is one test for Felix
> Http's filter support and Karaf makes use of Pax Web).
>
> Regards,
> O.
>
>> -Bertrand
>

Reply via email to