Scott, Thanks, it's a good thought; they are DHCP. Now that you say that, I guess I'm a little surprised that the IP hasn't changed at all despite so many reverts/reboots.
When the slave is disconnected, it shows as disconnected in Jenkins. I did verify that. I definitely get where you're coming from but I'm thinking that if another machine is starting up while the VM in question is down and that machine gets the VM's IP address, wouldn't it have to have a Jenkins slave on it in order to get me into this situation? Part of starting the Jenkins slave from the command line is passing in the exact URL to that node on the Jenkins server. I had thought that maybe I had let someone clone my VM and they never turned off the Jenkins slave, and that in fact someone's VM was trying to reconnect with the same name, but I think I cleaned up that issue by renaming the node on Jenkins recently as another potential fix. I may give this a try. Will let you know if it helps. On Monday, April 28, 2014 2:52:05 PM UTC-4, SA Evans wrote: > > Matthew, just a quick thought that's not 100% related to your issue, but > is the first thing that came to mind when you said you're having issues > with a slave upon startup. Are these dhcp machines by chance, and is it > possible that this slave is somehow getting an ip address when it wakes up > of a machine that's already connected (or is it retaining an old ip address > perhaps for a bit?) We used to have this sort of problem with VM machines > on occasion when we'd suspend them between builds, and if I recall, putting > an ipconfig /renew fixed the issue, as it forced the local box to renew its > dhcp configuration each time it started up. > > I assume you've verified on the Jenkins server that the slave shows as > disconnected there when it's down? > > Scott > > > On Mon, Apr 28, 2014 at 1:39 PM, Matthew Forrestall > <[email protected]<javascript:> > > wrote: > >> So I'm looking for advice for the following situation: We have several >> automated front end smoke tests that all run within a reverted VM on our VM >> server. Initially I thought this would work well with the Jenkins slave >> installed as a service but quickly found out that Microsoft has locked down >> the ability for services to interact with the desktop to the point now >> where it seems like running automated UI tests directly through the Jenkins >> slave as a service is not an option. Also the slave wouldn't always >> reconnect to the main Jenkins server consistently after a revert, whether I >> had it already enabled in the VM snapshot or whether I had it disabled in >> the snapshot and enabled it using psexec after the revert. >> >> At any rate, I moved to a process whereby all of the smoke test VMs have >> a snapshot that are powered off. A batch file is installed in the Window >> startup folders that starts the Jenkins slave from the command line. The >> Jenkins workflow does the following: >> >> 1. Reverts the VM to the clean snapshot >> 2. Powers the VM on. >> 3. The batch file is executed after a short timeout and the Jenkins >> service is started from the command line. >> >> >> This has been the most consistent approach thus far, however, one of my >> VM slaves still has a random issue connecting back to the main server. The >> error states that the slave is already connected when it isn't, since once >> the VM is reverted, that slave should get disconnected. (I will post a copy >> of the error once it fails again). We attempted to mitigate this problem by >> adding a Jenkins CLI call to explicitly disconnect the slave, and that >> hasn't improved matters. >> >> Any thoughts or advice on a better approach to starting the Jenkins slave >> in a reverted VM? I appreciate the ability to see the log output of the >> automated tests right in the Jenkins console, so I'd really like to stick >> with the Jenkins slave rather than write another tool or use a different >> workaround. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
