continuous integration - Jenkins and multi-configuration (matrix) jobs

Question

Why are there two kinds of jobs for Jenkins, both the multi-configuration project and the free-style project project? I read somewhere that once you choose one of them, you can't convert to the other (easily). Why wouldn't I always pick the multi-configuration project in order to be safe for future changes?

I would like to setup a build for a project building both on Windows and Unix (and other platforms as well). I found this question), which asks the same thing, but I don't really get the answer. Why would I need three matrix projects (and not three free-style projects), one for each platform? Why can't I keep them all in one matrix, with platforms AND (for example) gcc version on one axis and (my) software versions on the other?

I also read this blog post, but that builds everything on the same machine, with just different Python versions.

So, in short: how do most people configure a multi-configuration project targeting many different platforms?

question from:https://stackoverflow.com/questions/7515730/jenkins-and-multi-configuration-matrix-jobs

Answer 1

The two types of jobs have separate functions:

• Free-style jobs: these allow you to build your project on a single computer or label (group of computers, for eg "Windows-XP-32").
• Multi-configuration jobs: these allow you to build your project on multiple computers or labels, or a mix of the two, for eg Windows-XP, Windows-Vista, Windows-7 and RedHat - useful for checking compatibility or building for multiple platforms (qt programs?)

If you have a project which you want to build on Windows & Unix, you have two options:

• Create a separate free-style job for each configuration, in which case you have to maintain each one individually
• You have one multi-configuration job, and you select 2 (or more) labels/computers/slaves - 1 for Windows and 1 for Unix. In this case, you only have to maintain one job for the build

You can keep the your gcc versions on one axis, and software versions on another. There is no reason you should not be able to.

The question that you link has a fair point, but one that does not relate to your question directly: in his case, he had a multi-configuration job A, which - on success - triggered another job B. Now, in a multi-configuration job, if one of the configuration fails, the entire job fails (obviously, since you want your project to build successfully on all your configurations).

IMHO, for building the same project on multiple platforms, the better way to go is to use a multi-configuration style job.