If you are using a job workspace to share build artifacts, you cannot allow a new build to start while a test job is running because the new build would mess up the artifacts currently under test. This means you can combine the build and test jobs into one job and not make your feedback cycle any longer.
If you are worried about the feedback cycle, you can tick the box "Allow concurrent builds" in the job configuration. -- Sami 2012/3/8 Neil Bird <n...@fnxweb.com>: > > I have a feeling I've posted this question before but not hit a resolution. > > We generally have split our jobs into 2: one job does the build, and if > successful it triggers the test job. > > However, we have to run our tests over the build, and these are too large > to feasibly push to some shared location for the test job to copy, so what > we currently do is set the test job's custom workspace to be that of the > build job. > > The downside of this is that we have to tie both build+test jobs to the > same machine so as to guarantee visibility of the build. > > > Is there a way to let the build job pick a free box, and then make the > downstream job use the same machine? > > Maybe even a Jenkins command line at the end of the build that determines > the current machine and explicitly changes the config. of the downstream job > each time (although that'd be more unpleasant than our current tied-job > solution, I think)? > > -- > [neil@fnx ~]# rm -f .signature > [neil@fnx ~]# ls -l .signature > ls: .signature: No such file or directory > [neil@fnx ~]# exit
