[jira] [Updated] (SLING-6061) Create per-module Jenkins jobs

["Robert Munteanu (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Robert Munteanu updated SLING-6061:
-----------------------------------
    Component/s:     (was: General)
                 CI

> Create per-module Jenkins jobs
> ------------------------------
>
>                 Key: SLING-6061
>                 URL: https://issues.apache.org/jira/browse/SLING-6061
>             Project: Sling
>          Issue Type: Improvement
>          Components: CI
>            Reporter: Robert Munteanu
>            Assignee: Robert Munteanu
>
> As discussed on [dev@sling: CI alternatives for Sling|http://markmail.org/message/mdn4anwe6kxqxa2z] we should investigate generating per-module builds instead of having 'full' builds.
> The reason is that our currently large builds are slow and feedback is useless since most of the times at least one module is failing.
> We will first prototype a build using the Jenkins [Job DSL Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin], which will allow us to programatically define what build jobs are generated and their configuration.
> The proposed approach is to gradually transfer project from a large job to per-module jobs, using the following mechanism ( details to be filled in ):
> * create a mechanism which will allow us to skip building some modules on Jenkins
> * create a Jenkins DSL Job config in SVN which will generate builds for specific modules ( the i18n module is a good candidate, since it is flaky on Jenkins recently )
> * exclude the 'modularised' build modules from the main build
> In time, we will move out all bundle modules from the current reactor and we should have the following main classes of build jobs:
> * bundles
> * launchpads ( main, contrib, etc )
> * utility modules ( testing )
> * integration tests
> * tooling/maven
> * tooling/ide
> Note that this does not exclude 'bigger' modules like for instance Sightly which contain bundles, content and integration tests. At first I'd like to get a feel of what solution is best for us.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)