Hi, sorry for the late answer, I was busy with other things. Copy artifacts seems to be the thing that would fit perfectly, thanks for the suggestion! Running everything in one job is no alternative because it would take more than 2 hours until all the tests are ready. I have 12 executors in parallel at the moment to run the tests so our build-cycle is only 15 minutes now. I had a shared workspace in the beginning but this caused problems, too. Some test projects use the same deployment files which sometimes led to test failing because the resource was blocked by another test. And sometimes xunit plugin found got confused when parsing test results when two jobs were ready at the same time so you could find the results of both test projects at each project.
But I just implemented a pilot job with copy artifact. Unfortunately I have two new problems with that: 1. Why is copying the files taking that much time (about 16 minutes)? 09:05:06 Started by upstream project "ContestContinuous" build number 3456 09:05:06 Building remotely on 1SP1-SLAVE1 in workspace C:\Jenkins-Slave\workspace\ClimateChamberTest 09:05:06 No emails were triggered. 09:21:43 Copied 813 artifacts from "ContestContinuous" build number 3456 10:02:58 [ClimateChamberTest] $ cmd /c call C:\Users\KUYPER~1.1SP\AppData\Local\Temp\hudson662483330654974304.bat Here is an old build with copy-workspace-scm plugin (same file set, I did just copy and paste for copy artifacts): 15:25:03 Started by upstream project "ContestContinuous" build number 3447 15:25:03 Building remotely on 1SP1-SLAVE1 in workspace C:\Jenkins-Slave\workspace\ClimateChamberTest 15:26:54 No emails were triggered. 15:26:54 [ClimateChamberTest] $ cmd /c call C:\Users\KUYPER~1.1SP\AppData\Local\Temp\hudson356075031990640251.bat 2. I loose the changes from the compile job in the test job. With the old setup I fingerprinted one certain file in the compile and in the test job and with that due to some magic the unit test job now knew about the changes of the upstream job. Now this relation is somehow gone, although the compile job automatically fingerprints the same file (and many others) and I din't change the fingerprinting in the test job. Thanks for further hints on that Dirk 2012/2/11 Sami Tikka <sjti...@gmail.com>: > 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 -- Never trust a short-haired guru
