Open Source is Painless (Theme from JBDS)

With JBDS 5.0.0.CR1 and JBoss Tools 3.3.0.CR1 out, and GA/Final releases just around the corner, it's high time for a new song.

Hell's bells, it's been over 3 years since my last music-related post.

The idea for doing this song came after spending a day creating a diagram showing how JBoss Tools and Developer Studio are built, followed by myarboro's reaction to the complexity.

Diagram by Dia

Through early morning mail I see
Visions of JIRAs for me
Build jobs red unexpectedly
I realize and I can see...

That Open Source is painless
Even with non-stop changes
And yet we give all this away for free

The game of rel-eng's hard to play
We struggle through it anyway
A business card I'll never lay
Deprecated: it's LinkedIn's day

Jenkins builds are painless
They track so many changes
And ever onward moves complexity

The use of Git trumps SVN
But migrating's hard to begin
When your code base is not so slim
The pain grows stronger... bear & grin

Using github's painless
Pull/push requests for changes
And I can take or leave it if I please

A Turing test once asked of me
To answer questions that are key
'To use Tycho or PDE?'
And I replied 'Not PDE!'

Releng'ing is painless
It is a game of changes
And still we give all this away for free
And you can do the same thing if you please...

Johnny Mandel & Mike Altman - Suicide is Painless (Theme from M.A.S.H.)

Managing Jenkins job configurations

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.