In JBoss Tools and Developer Studio, we manage a lot of build jobs in Jenkins. In fact, for the 3.2.x/4.x and 3.3.x/5.x streams, there are over 195 jobs. When we start building our next year's first milestone, we'll spawn another 40+ jobs.
Here are some of them:
- http://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_Trunk/
- http://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_3.3.indigo
- http://hudson.jboss.org/hudson/view/JBossTools/view/JBossTools_3.2.helios
To assist in performance, we use maven profiles in our parent pom to allow data to be shared outside the slaves' workspaces, without using shared workspaces (as that can lead to conflicts when multiple maven processes try to write to the same .m2 repo). Here's an example:
<!-- same contents as jbosstools-nightly-staging-composite, but locally
available (to improve network lag) -->
<profile>
<id>local.composite</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<repositories>
<repository>
<id>local.composite</id>
<url>${local.composite}</url>
<layout>p2</layout>
<snapshots>
<enabled>true</enabled>
</snapshots>
<releases>
<enabled>true</enabled>
</releases>
</repository>
</repositories>
</profile>
We also use profiles to turn on code coverage analysis or to take advantage of Jenkins variables like BUILD_NUMBER when setting a timestamped qualifier for features & plugins:
<profile>
<id>hudson</id>
<activation>
<property>
<name>BUILD_NUMBER</name>
</property>
</activation>
<properties>
<local.site>file:///home/hudson/static_build_env/jbds/target-platform_3.3.indigo.SR2/e372M-wtp332M.target/</local.site>
</properties>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-packaging-plugin</artifactId>
<version>${tychoVersion}</version>
<configuration>
<format>'v'yyyyMMdd-HHmm'-H${BUILD_NUMBER}-${BUILD_ALIAS}'</format>
<archiveSite>true</archiveSite>
</configuration>
</plugin>
</plugins>
</build>
</profile>
But how do you deal with hundreds of jobs' config files, and how do you update them all easily w/o hours of in-browser clicking?
We maintain the job config files (config.xml) offline.
To do this, we use a maven plugin I wrote to fetch jobs matching a given view & regular expression and store them locally on disk using the same structure as on the server.
Then that same plugin can be used to push the config.xml files BACK to the server after making changes to one (or all) the files.
For an extra level of auditing, we also commit these locally cached config.xml files to SVN so we can track their history. Admittedly Jenkins provides this functionality natively, but when you're POSTing changes to config.xml files the server doesn't always notice a change and record the delta, so having a backup (particularly one you can diff offline) is never a bad idea.
