This page is not yet complete, please ask on the dev@sling.apache.org mailing list if anything is unclear or out of date

History and current status

We maintain a (large) number of jobs on the ASF Jenkins instance. Historically, we had a few large reactor builds but those proved to be of limited usefulness:

the builds were quite slow to complete - 50 minutes on average

if a module in the reactor failed, the whole build failed

In practice, this meant that the Sling CI jobs were red almost all of the time.

To solve these issues we have decided to create individual jobs for each module. Given that Sling has a large number of modules, it is unrealistic to manage them all manually. As such, we have started using the Jenkins Job DSL Plugin . This allows us to programatically create jobs based on a groovy script.

Views

Managing jobs

Since all the job management is now done via a Groovy script manual job creation is discouraged. Altering an existing job is also discouraged since the changes will be undone when the jobs are next regenerated.

Per-job customisations can be applied by creating a Sling module descriptor in the git repository root, see Sling module descriptor for details.

If any of these things change, the seed job must be executed to update the generated jobs.

SNAPSHOT parent versions

Jenkins can usually not resolve parent pom SNAPSHOT versions. The main reason for that is that the SNAPSHOT repo url is only defined in the ASF parent (being itself a parent of the sling-parent). The settings.xml being used on all Jenkins instances does not define that repo url. For a detailed explanation look at .

The following snippet can be added as workaround to the project pom.xml which references a SNAPSHOT parent to be able to build it with Jenkins.

Pax-Exam tests with SNAPSHOT dependencies

Pax-Exam tests using SNAPSHOT versions are problematic since they have no way of knowing the general Maven context and they don't obey the custom Maven repositories. As such, we need to manually define the Apache SNAPSHOT repository for those tests. One issue were this was done is .

If you're using the org.apache.sling.testing.paxexam module, this is already incorporated as of version 0.0.3-SNAPSHOT.

Also, if a Pax-Exam test depends on a SNAPSHOT version of another Sling bundle, the project holding the test will not be rebuilt when a new SNAPSHOT of the included bundle is deployed. This only works if there is a dependency to that bundle and the required version in the pom.xml file.

Testing more complex changes with Docker

If you wish to perform more complex changes, affecting the logic of the script, it's recommended to test these changes on a separate Jenkins instance. This way you minimise the chances that something goes wrong on the ASF Jenkins instance and you get very quick feedback. As of 2016-10-01, a run on sling-seed-build on builds.apache.org takes between 10 and 90 minutes.

If you wish to test the actual job execution, label the master with the "Ubuntu" label. Otherwise, only the seed job will run.

Limitations

We rely on the Jenkins Maven Plugin to automatically detect relationship between jobs, e.g. from org.apache.sling.distribution.core to org.apache.sling.distribution.api . However, this does not take into account the provisioning model. To work around this, we currently set up some very broad rules, such as 'all entries under bundles/ or installer/ trigger a launchpad build'. Also, we manually set some dependencies between some of the launchpad testing jobs. We might revisit this to see if we can do something more fine-grained.