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.
HTH. -Andrei On Mon, Sep 19, 2016 at 9:50 PM Robert Munteanu <romb...@apache.org> 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 <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/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@pro-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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
