2012/2/15 Dirk Kuypers <kuypers.d...@googlemail.com>: > Running everything in one job is no alternative > because it would take more than 2 hours until all the tests are ready.
OK. But you do know it is possible to run several builds of one job concurrently? Check the "Execute concurrent builds if necessary" on job configuration page. > 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 That's quite a lot of artifacts. How much data is that? I wonder if the author of the Copy Artifacts plugin is reading this? Another possibility is to not use Copy Artifacts plugin and do things the old-fashioned way: use wget or curl to download the artifacts. In your case, I probably would not download 813 files individually. I would download the link that provides all artifacts as one "archive.zip" package. > > 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 Strange. I would have thought it takes much longer to copy a full workspace than some artifacts. I admit I haven't used the Copy Workspace SCM plugin a lot. I did some testing with it but found it slow and did not use it any more. > 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. You need to fingerprint and archive one unique build artifact in the upstream job, then copy that artifact into the downstream job and fingerprint it in there too. When Jenkins sees the same fingerprint in two builds, it knows they are connected. -- Sami
