Experience with Hudson - Building matrix project

Question

Did anyone try that feature and has some feedback? Or Does anyone know some useful samples to look up?

Answer 1

I have tried this feature some months ago, but I don't use it anymore (just because I don't need it, not because it is not a good feature).

Basically, you define n Axis, each axis is a property with several values.

Let's go with an example: you define the Axis "JDK", with possible value "1.4", "1.5", "1.6", and you define another property "database", where possible values are "oracle", "mysql".

Thus, Hudson will launch your build 6 times:

• with JDK 1.4, with the property database=oracle (i.e. the JVM is launched with -Ddatabase=oracle)
• with JDK 1.5, with the property database=oracle
• with JDK 1.6, with the property database=oracle
• with JDK 1.4, with the property database=mysql
• with JDK 1.5, with the property database=mysql
• with JDK 1.6, with the property database=mysql

Then, once everything is finished, you will be able to see the results for each iteration.

This feature may be really usefull when you need to test your application in several environments (in my example, with different versions of JDK or database).

Note that except for the JDK axis, you have to manage by yourself the property given as entry by Hudson. In my example, the application must take into account the "database" property itself. Eventually, a good idea is to use this property to enable a particular profile in the Maven2 configuration, if you project is mavenized (see here for more details about that).

I hope my explanations are clear enough :)

Answer 2

Matrix builds have a number of issues:

• Broadly incompatible with plugins - they are getting better, but you need to be keeping very much up to date.
• Artifacts - much harder to wriggle out - URls are a little more awkward, finding them on the FS (which you should avoid anyhow) is now a nightmare.

Which is a shame, because the concept is very good and very handy where it works.

---

Edit

• Inability to start single points.

Our usual way around this is to have parameterized builds set up to run concurrently - which comes with its own problems, but saves us having many jobs with the same code and different constants.