In Jenkins it is usually a bad idea to use another job's workspace because you cannot precisely control what gets executed and when.
You have 2 possibilities: 1) the best practice using Jenkins is usually for the compile job to archive the build artifacts. This means that a configured set of files will be copied away from the job workspace to a build specific archive area where they are safe. The unit test jobs can then be triggered and they can use the copy artifact plugin to get a copy of the artifacts. If you want, the compile job can even pass its build number to the unit test jobs. 2) If your unit tests need to use the compile job workspace directly because the compile artifacts are so huge they cannot be reasonably copied around, your should consider executing the unit tests in the same compile job. Another idea: I recently learned there is a plugin that creates a new build step where you can trigger another job and wait for its completion. This might be useful to you but I cannot remember what the plugin was called. -- Sami Dirk Kuypers <kuypers.d...@googlemail.com> kirjoitti 9.2.2012 kello 16.42: > Hi, > > is it possible to block a build as long as downstream projects are > queued, but not running? > > Background: We have a continuous compile job triggered by SCM changes > which starts about 30 unit test jobs after successfull compile. Most > test jobs copy their workspace via copy-workspace-scm plugin from this > compile job. Compile takes about 5 minutes, some test projects 10 > minutes and longer. The round-trip build cycle is around 18 minutes at > the moment. When I disable "Block build when downstream jobs are > running" at the compile job it will happen, that there are some tests > queued from the previous build which will get started after the second > compile is successfull. So those tests get their workspace from the > second compile and not from the first one. If the second compile job > had to wait untill all remaining tests left the queue and entered the > state running I think it would be save to start the next compile (and > could save us about 5 minutes in our build cycle). > > Another possibility would be to tie the unit-test job to its starting > compile job with the workspace attached and not to "Most recent > completed build". > > Any thoughts on this? Any other way to achieve my goal? > > Dirk > > -- > Never trust a short-haired guru
