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

Reply via email to