+1 to the pipeline plugin.

Info on the other CI builds.
There is a build that builds pull requests from GitHub in Jenkins, IIRC its
only JDK8 and doesn't have tests enabled as there were too many false
negatives, but I would need to check that.
Also there are Travis CI builds for JDK8 and JDK7, the JDK7 one is disabled
and the JDK8 doesn't run integration tests. The Travis CI builds tend to
come back faster than Jenkins at the moment, and will run all you ask it to
in parallel, so a CI matrix is viable without a pipeline.

Ideally all those builds should be running tests and run on JDK8 and JDK7
but while some of the tests remain unstable a false negative is not
helpful.

If you want to change the travis builds, commit or patch to .travis.yaml.
Try to keep the volume of output down. > 1000 lines causes the build to
fail, and no output for > 10min also fails the build, hence some of the
slightly odd build commands in the .travis.yaml file.

Best Regards
Ian

On 19 September 2016 at 17:04, Andrei Dulvac <andrei.dul...@gmail.com>
wrote:

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

Reply via email to