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

Reply via email to