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]>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]. > 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.
