There is a not crunchable issue you have to reboot the machine/service while building. You won't get a job status and this breaks the build queue. No follow up job will run that way. I have been in a similar situation but really had to reboot the Jenkins. Normally a build step with "call reboot.bat" would put the batch stack on hold while executing reboot.bat and a simple "reboot.bat" should let the batch stack simply run to its end - no matter what reboot.bat makes in the meantime or even still is running after the batch stack/build step has finished. That's not working on Jenkins. Probably to return a build status that reflects everything. This behaviour makes sense but gives you some hard times if you have to do things in a certain but awkward style.
- I did install the Startup Trigger<http://wiki.jenkins-ci.org/display/JENKINS/Startup+Trigger>plugin and Jenkins Exclusive Execution Plugin<http://wiki.jenkins-ci.org/display/JENKINS/Exclusive+Execution+Plugin>. This way you can spawn jobs as soon as Jenkins goes online auotmatically and execute the new job described below without any impact on other job. It will wait and block the queue until it can run solely. - A job has been placed between the build job before and after reboot. - The pre-reboot job triggers this new job. That manipulates the config.xml of the post-reboot job. - The parameters are changed with sed Build parameters and the Startup Trigger<http://wiki.jenkins-ci.org/display/JENKINS/Startup+Trigger>switch are set - It executes a command to restart the service - On restart is the post-reboot job doing whatever needed and rewrites its own configuration in a post build action to unset the Startup Trigger<http://wiki.jenkins-ci.org/display/JENKINS/Startup+Trigger> Not a nice approach but in my case the only feasible solution atm and I've been crunching brain for month to figure this approach out. Our infrastruture had some nice obstacles at hand for me. We are authenticating versus CTF 6.x and that did make it as hard as imaginable. This new job has no build history as it never finishes to write a build history :/ But I don't care. It works and the two other jobs have a history which is suffice. Take care Jan Am Donnerstag, 17. Mai 2012 21:47:51 UTC+2 schrieb DJM: > > As other have suggested, you should use run your tests upon a jenkins > slave node. We have a similar problem to you and we do this: > > Jenkins -> Test Driver -> System Under Test > > Here, Jenkins communications directly with the Test Driver; the test > driver communicates with several 'Systems Under Test'. Test Driver can > communicate with VMware or EC2 to reset VMs or provision complex EC2 > setups. Our Test Driver polls until all our nodes are on-line and ready to > be tested. > > Hope this help. > > Dominic > > On Wed, May 16, 2012 at 9:59 PM, Romu <huru...@gmail.com> wrote: > >> Hi, >> >> How to reboot a slave as part of a build? I found that when the slave >> reboots Jenkins immediately considers the build as failsure. >> >> Any idea? >> >> Thanks >> Romu >> > > > > -- > Dominic Maraglia > QA Engineer > Puppet Labs > >
