Hi Andrei, (Kind request - please don't top post, at least not in a long conversation thread which uses bottom-posting, it's quite hard to understand what you're replying to :-) )
On Tue, 2016-09-20 at 09:45 +0000, Andrei Dulvac wrote: > Hi Robert, > > Have a quick look at https://jenkins.io/doc/pipeline/jenkinsfile/ > It is a jenkins 1.X plugin, formerly known as "Workflow plugin": > https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Plugin > It is part of jenkins 2.0 now (https://jenkins.io/2.0/) and it will > definitely surpass usage of the Job DSL plugin, which is in the same > space. I've read about the pipeline plugin, I've seen comparisons with the Job DSL plugin, but nowhere have I found how to automate job generation with the pipeline plugin. With the Job DSL plugin I can have one 'seed' job which automatically generates and updates an arbitrary number of jobs. This is what I'm looking for since I don't want to manually maintain 50 or more per- module Jenkins jobs. If you can point me to that specific functionality in the pipeline plugin I'd be happy to build on top of it. Otherwise, I will stick with the Job DSL plugin. Robert > > HTH. > -Andrei > > On Mon, Sep 19, 2016 at 9:50 PM Robert Munteanu <[email protected]> > wrote: > > > > > On Mon, 2016-09-19 at 18:02 +0200, Konrad Windszus 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. > > > > AFAIU the pipeline plugin defines a pipeline, but that's not what > > I'm > > looking for at first. I skipped the documentation and the examples, > > but > > I could not find an example about how to create jobs using the > > pipeline > > plugin. > > > > I want to use the Job DSL plugin to define a large number of jobs > > programatically, rather than maintain them by hand. > > > > In the future we can orchestrate these jobs by using the pipeline > > plugin. > > > > Of course, if anyone can point me in the direction of generating > > jobs > > using the pipeline plugin, I'd be happy to use just that. > > > > Thanks, > > > > Robert > > > > > > > > > > > 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 <rombert@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.mb > > > > ox/b > > > > rows > > > > 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@pr > > > > > > o-vi > > > > > > sion > > > > > > .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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
