On possibility that we've used for similar situations: - Create a lock (Lock and Latches or Throttle plugins) for each slave that you're going to test on. - Set the slave up to accept only targeted jobs - that way other jobs won't wander onto your slave. Also, the slave must be setup to automatically start the slave agent on reboot, you cannot have the Jenkins start the slave. - Create a "master" job. This job will obtain the lock for the slave that will be reboot. - The "master" jobs spawns - and WAITS - for a "pre-reboot" job via the Trigger Parameterized Job build step on the node using a Node parameter. - The "pre-reboot" job runs on the slave, does it's stuff, then initiates a reboot of itself. The job terminates. - The "master" returns from the wait, then initiates another wait while waiting for the slave to get far enough into the shutdown that the slave agent isn't running. - The "master" job spanws - and WAITS - for a "post-boot" job, just like the "pre-reboot" job. Jenkins will queue the job up until the slave takes it. - "Post-boot" job runs and does it's stuff. - The "master" returns from the wait and does anything it needs to.
This general approach should work. Jason On Friday, September 28, 2012 8:43:47 AM UTC-7, Jonathan Rice wrote: > > I'm doing a project which involves building and testing drivers on OS X. > Testing would happen on dedicated slave machines, but the snag is that > after installing the drivers, the machine must be rebooted before > functional testing is started. I can think of two general ways to approach > this in Jenkins - I'd be grateful for any advice as to which (or other > approaches) might be workable: > > 1. Design a single Jenkins build job that includes an initial driver > install and reboot, and then runs its functional tests after the reboot. I > can certainly arrange for daemon code to be run after a reboot on OS X, > but > I suspect there's no way to make the post-reboot work appear to the master > as part of the same job. I presume the master will always think the job > ended at the reboot. > 2. Make the install & reboot be a first build job, and then arrange > for the functional tests to be the next build job on that same slave. I > suppose this might be done in some way with node labels - a single node > per > slave, labeled with the machine name, or other distinguishing id. But for > this to work, the initial install/reboot job would have to block all other > jobs from that slave until the functional test job had been scheduled and > completed. Does Jenkins have any way to schedule successive jobs to the > same slave like this? > > If anyone has any advice on these or other methods, please let me know. > Thanks! > > -- Jonathan >
