On Mon, 2016-09-19 at 15:53 +0200, Carsten Ziegeler wrote: > 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.
I pinged infra about this and noone opposed :-) http://mail-archives.apache.org/mod_mbox/www-builds/201609.mbox/brows er I would be happy to look into per-module builds based on Jenkins. I've done some work automating similar setups in the past using Job DSL plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin I can file a request for infra to install this plug-in and start testing on a limited set of modules if no one objects. We can then gradually migrate modules off the 'main' job and move them to individual jobs. Thanks, Robert > > 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 <sseifert@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 > > > > > > > > > > > >
