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
> > > 
> > > 
> > 
> 
> 
>  
> 

Reply via email to