Jenkins on Windows and GUI Tests without RDC

StackOverflow https://stackoverflow.com/questions/10177708

Question

We have a master-slave configuration for Jenkins. Our .NET project is built by a slave Jenkins instance running on Windows.

There are a bunch of GUI tests, however they only seem to run if there's a remote desktop connection (RDC) session open.

When trying to run the tests with no RDC, Jenkins doesn't show any progress in testing. Then, however, I connect to the Slave's desktop and can see the main window of the application launched, however the UI testing framework (White) cannot perform any actions.

The Jenkins slave is launched via Java Web Start.

I read on several websites that unfortunately it is not possible to run GUI tests without RDC session.

I just want to confirm that it is true and wonder if there is any workaround.

Was it helpful?

Solution

Your slave machines have to be at a desktop before the test can run properly. We had the same problem.

Solution was to have the test machine start up and auto-logon to the desktop. To ensure that the test would ONLY start after the desktop was available, we added a scheduled task, set to run at user login, that would launch the Jenkins slave via Java Web Start. That way, Jenkins would only see the slave once the desktop was running. After that, everything worked fine.

OTHER TIPS

I have a Jenkins cluster running different kinds of GUI testing, win32, swing, selenium. They are running thousands of tests in unattended manner 24x7. Here is my solution:

  1. How to keep GUI testing alive - RDC doesn't work, the GUI applications will only function well when the RDC session is active. I've tried different ways, so don't bother to try again. Your test would broke after the RDC window is minimized or disconnected. The solution so far is install VNC Server (I am using UltraVNC) as service and make sure it is started during log on. Also make sure you don't connect to your test machine with RDC, as RDC will break VNC session. If possible connect it with VNC client as well. But that is up to you. What I do is when I need to debug something on the machine, I RDC to it and restart it to make sure #2 and #3 are set.

  2. Auto logon - there is a tool autologon.exe in SysInternalsSuite, run it on your slave

  3. Auto register slave - What you need is Swarm Plugin - https://wiki.jenkins-ci.org/display/JENKINS/Swarm+Plugin . Write a simple batch and place a shortcuts in your startup folder. Everytime your machine autologon, it is automatically registered as slave.

I actually combine #2 and #3 as a simple batch file:

autologon.exe <user> <domain> <password>
REM Here to make sure the logonCount is properly generated
REG ADD "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AutoLogonCount /t REG_DWORD /d 0xFFFF /f

start /min java -jar I:\CDC\jenkins\swarm-client-1.9-jar-with-dependencies.jar -executors 1 -fsroot c:\Jenkins -labels "Prod Win7 %ComputerName%" -master <Jenkins URL> -name farm-%ComputerName% -username <username> -password <password>

There is another way of do it without windows auto logon (works for me on few machines).

1. Go to Computer Management -> Services and Applications -> Services -> Jenkins Slave -> Properties
2. In Log On tab chose Local System account and check Allow services to interact with desktop
3. Close this windows by clicking OK, and restart the Jenkins slave service
4. Go to directory where is your test app and chose Properties on your app executable
5. On Security tab click Edit...
6. In new window click Add..
7. In new window click Locations... and chose Local computer (top most option on list), click OK
8. Put LOCAL SERVICE to white area of the window and click Check Names, click OK
9. Allow Full control for that user, click OK, close all windows

That should be everything. Let me know if it works for you.

As the other answers already stated, one needs a configuration, where the windows machine auto logons to a real user, see other answers for details. However this was not enough for me, I needed to setup a UltraVNC Server as running as service to solve the problems.

On the site is mentioned, that a login via RDP is a problem for that trick, i.e. connect with VNC or reboot after RDP access.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top