I'm also new here - but possibly facing similar problems (C#). I'm not sure how exactly you expect the dependencies to be "handled", but I thought I would post my opinion.
I am going for your option B "one job for each project?" My current plan is to add "build other project" "post build tasks" to jobs that are depended upon. If I understand correctly, by doing this I can "Block build when upstream project is building", and "Block build when downstream project is building". Since I want immediate feedback, regardless of what is happening elsewhere, I'm NOT going to use these. Maybe you want to... I will also use the Copy artifacts plugin for projects that have dependencies to use the last successfull build from the upstream project. Below is a sample setup with some possible problems. Job A (triggered by a code checkin to repo somerepo/A,with with post build task to to run Job B) Job B (triggered by a code checkin to repo someotherrepo/B AND has a dependency on Job A) Problem 1 Scenario A Two different developers check in changes simultanuously to the two different repo's. Since the changes do not depend on one another, both jobs should be allowed to run simultanuously (job B can use the last successful build of job A's artefacts). When Job A is done, the post build task will run Job B a second time. Scenario B A single developer checks in changes to both repos at the same time - the changes depend on each other. The jobs will be run as described in Scenario A - which causes Job B to fail. The second run of Job B should fix this. I think scenario B will not happen often - and I can accept a failed build in this case. Is this the type of "handling" you are asking about?
