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
