How to run jobs in Hudson in some predefined order?

Question

There are 4 jobs:

Build1  
Build2  
Test1  
Test2

Build1 and Build2 can be started simultaneously.
Test1 should be started only when both Build1 and Build2 will be finished.
Tes2 should be started only when Tes1 will be finished.
Also I would like to have ability to start all of these jobs separately.
Is there any way to setup jobs according these rules?

Answer 1

When creating a new job, you normally can specify what upstream project must be built in order to begin this job.

This option is in Build Triggers -> Build after other projects are built when creating/modifying a job.

Answer 2

I think you have several options. My assumption is, that we are talking about long running jobs, otherwise I would just string them together as one monster job (several build steps in one job) and create separate jobs for running them individually.

As mentioned, for long running jobs, have a look at the join plugin. As a general FYI there is a page explaining why you want to separate testing jobs from the building jobs. See here.

Answer 3

The "Promoted Builds Plugin" can be a good solution: you can configure a master job "Build" to do nothing but start 2 downstream builds "Build1, Build2" (in post-build actions). Then you have to add a promotion process "When the following downstream projects build successfully" selecting "Build1, Build2", with an associated downstream build action of "Test1". If "Build1" and "Build2" build sucessfully (both status STABLE), "Build" will be promoted and "Test1" will be enqueued. Finally, you trigger Test2 as a post-build action of Test1.

But you have to be aware that is case many instances of "Build" are enqueued, you cannot rely on the lastSuccessful build permalink (the next "Build1" or "Build2" may already be built when "Test1" called by the first "Build" will pop-out of the queue), and you will have to devise a way to keep track of the revision of the build you are testing.

Parameterized Trigger Plugin can help solving this problem: you could pass the id of the upstream build as a parameter, for example.