The benefit of the current solution is clear: below or equal to zero.
Afaik, Robert look already into having per module jobs in jenkins. Not
sure how far this is.
Carsten
> +1 for openly talking about this. I think the most important thing is
> clearly understanding the benefits and drawbacks for the different ways of
> building continuously.
>
> On Mon, Sep 19, 2016 at 3:43 PM Stefan Seifert <sseif...@pro-vision.de>
> wrote:
>
>>> for quiet some time now, it seems that the IT tests of the i18n module
>> fail in reactor build
>>
>> i also had a brief look at the tests of the i18n project and was not able
>> to spot the problem easily.
>>
>>> I suggest we turn off Jenkins completely
>>
>> do we have an alternative?
>>
>> ian invested a good amount of time in getting the sling CI running in
>> travis, not sure what the status ist.
>> currently it seems JDK 1.8 builds run fine, JDK 1.7 builds not [1].
>>
>> in my pov the main problem of our CI builds are that we have two really
>> huge builds that build everything ("production bundles" and contrib), and
>> if one of them gets flaky all gets flaky, and it is extremely
>> time-consuming trying to fix a problem, wait some hours, try again etc.
>> plus the fact a lot of problem on the apache Jenkins are difficult to
>> reproduce locally.
>>
>> most sling bundles (or small group of bundles) are quite autonomous. when
>> we had a CI build for each of them individually this would be much easier.
>> if one breaks the CI is still functional for the other 99% bundles. this
>> leads again into the svn vs. git and huge repo vs. small repos debate, and
>> of course no one wants to maintain a huge set of CI build configurations
>> individually, we would need to automate this.
>>
>> in the past it was difficult to get a consensus on those topics (scm, ci)
>> on this list. perhaps we can have a discussion on this on the adaptTo() in
>> berlin next week.
>>
>> stefan
>>
>> [1] https://travis-ci.org/apache/sling/builds
>>
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
