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?
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.
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.
I'm running version 1.346 of Hudson.
You can check 'Build after other projects are built' under 'Build triggers'.
It says that "Multiple projects can be specified like 'abc, def'"
So you should be able to add 'Build1, Build2' to that field in the configuration for Test1.
You could keep your Test1 & Test2 as separate jobs, instead of being a part of the builds.
When Build1 and Build2 are complete, Test1 can start as a downstream build. Test2 can be a downstream job from Test1.
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.