Reconfigure and reboot a Hudson/Jenkins slave as part of a build

Not sure if this will work for you, but you might try making the Jenkins agent node programmatically tell the master node that it's offline.

I had a situation where I needed to make a Jenkins job that performs these steps (all while running on the master node):

• revert the Jenkins agent node VM to a powered-off snapshot
• tell the master that the agent node is disconnected (since the master does not seem to automatically notice the agent is down, whenever I revert or hard power off my VMs)
• power the agent node VM back on
• as a "Post-build action", launch a separate job restricted to run on the agent node VM

I perform the agent disconnect step with a curl POST request, but there might be a cleaner way to do it:

curl -d "offlineMessage=&json=%7B%22offlineMessage%22%3A+%22%22%7D&Submit=Yes" http://JENKINS_HOST/computer/THE_NODE_TO_DISCONNECT/doDisconnect

Then when I boot the agent node, the agent launches and automatically connects, and the master notices the agent is back online (and will then send it jobs).

I was also able to toggle a node's availability on and off with this command (using 'toggleOffline' instead of 'doDisconnect'):

curl -d "offlineMessage=back_in_a_moment&json=%7B%22offlineMessage%22%3A+%22back_in_a_moment%22%7D&Submit=Mark+this+node+temporarily+offline" http://JENKINS_HOST/computer/NODE_TO_DISCONNECT/toggleOffline

(Running the same command again puts the node status back to normal.)

The above may not apply to you since it sounds like you want to do everything from one jenkins job running on the agent node. And I'm not sure what happens if an agent node disconnects or marks itself offline in the middle of running a job. :)

Still, you might poke around in this Remote Access API doc a bit to see what else is possible with this kind of approach.

Very easy. You create a Master job that runs on the Master, from the master job you call the client job as a build step (it's a new kind of build step and I love it). You need to check that the master job should wait for the client job to finish. Then you can run your script to reconfigure your client and run the second test on the client.

An even better strategy is to have two nodes running on your slave machines. You need to configure two nodes in Jenkins. I used that strategy successfully with a unix slave. The reason was that I needed different environment variables to be set up and I didn't wanted to push that into the jobs. I used ssh clients, so I don't know if it is possible with different client types. Than you might be able to run both tests at the same time or you chain the jobs or use the master strategy mentioned above.