[
https://issues.apache.org/jira/browse/SLING-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15531031#comment-15531031
]
Robert Munteanu commented on SLING-6061:
----------------------------------------
Right now all of the bundles and utility modules built by the 'default' reactor
have been migrated to individual jobs. I still have a small number of errors to
clear up; some of these are related to configuration/build order, but some of
those might be a little tougher ( e.g. the health check ITs try to find
SNAPSHOT bundles with pax-exam, but that setup is unaware of the
repository.apache.org snapshots repository ).
The main sling-trunk-1.8 job now only builds the 'launchpad' modules. After
stabilising the modules I will:
- deactivate the sling-trunk-1.8 job
- create individual jobs for the launchpad modules
- establish dependencies from the bundle to the launchpad builder module
- establish dependencies between bundle jobs themselves ( e.g. validation impl
dependends on validation api )
Then the 'main' cycle is complete and contrib and samples will follow.
> Create per-module Jenkins jobs
> ------------------------------
>
> Key: SLING-6061
> URL: https://issues.apache.org/jira/browse/SLING-6061
> Project: Sling
> Issue Type: Improvement
> Components: General
> 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)
