For the record, this is now done. Robert
On Wed, 2016-09-28 at 22:52 +0000, Stefan Seifert wrote: > discussed at the Sling Committer Round Table @ adaptTo() 2016 > > we all agreed that we need CI build individually per module/bundle, > not a big build for all bundles at once. > > benefits: > - much faster feedback in case of a broken build, and much more > specific > - if one module is broken only it's own CI build is affected, all > other are still green > - CI build for one module is much faster, leading to much shorter > debugging cycles in case of problems > - it's much easier to use tools like travis without having to work > around build time and log output size limitations > > alternatives discussed: > - we were very unhappy with the apache Jenkins lately, but the reason > may be that the single full CI build was just too big and fragile > - travis would be a simple option to use esp. when sling is migrated > to git and we have one single git repo per module. bertrand pointed > out there is an official support from ASF to use travis. > - we could ask infra to support us with our own jenkins instance we > maintain ourselves. but we do not want to go this way due to its > maintance efforts unless there is no other way. > - we decided to stick with the ASF Jenkins for now, and got the way > to CI builds for each module which robert has already started in > SLING-6061 > > robert currently uses the jenkins job DSL plugin to auto-generate new > jobs and update existing jobs to the current job definition. the > source script and job definition template is maintained in svn, as > soon as this is changed all auto-generated jobs get updated. and > alternative would be to use the Jenkins pipeline plugin, but > currently we think creating individual jobs is easier for us to > understand and maintain. > > some requirements for the ci build ans integration: > > - it would be nice to have a CI build notification within the github > mirrors of the git modules showing red/green status on each commit > (which is available e.g. for travis - is it possible with the ASF > Jenkins as well?) > > - if new branches are created or PRs are submitted a CI build should > run for them as well, reporting it's status in the github views > > - the CI build should run for the supported JDKs for each module, > e.g. java7+java8 or java8-only > > - from the git project it the Jenkins CI job should be easy found. if > a common naming scheme for the Jenkins jobs is used which e.g. > include the git repo name this should be easy. > > - each CI job has to deploy the current module's snapshot to the > apache maven snapshot repo, to make it available to other builds. > > > stefan > > >
