Was going to write the exact same thing. The pipeline plugin, now just "pipeline" into jenkins 2, is the future and I would recommend using it. Except if there are plugins you want to use that are not supported yet.
-Andrei On Mon, Sep 19, 2016 at 6:02 PM Konrad Windszus <konra...@gmx.de> wrote: > Wouldn’t it make more sense to rely on the pipeline plugin instead of the > Job DSL Plugin? This is by default shipped in Jenkins since 2.0.0 so > probably there is not even the necessity to install an additional plugin. > For a comparison between those two approaches look at > http://stackoverflow.com/questions/37657810/job-dsl-plugin-vs-pipeline-plugin > . > > I don’t have any practical experience with either of those two approaches, > but since the Pipeline DSL gained a lot more attention from the Jenkins > community in the past I am wondering whether using that that is not enough > for Sling. > Konrad > > > > Am 19.09.2016 um 16:15 schrieb Robert Munteanu <romb...@apache.org>: > > > > 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 > >>>> > >>>> > >>> > >> > >> > >> > >> > > > >
