Sikuli Running on Hudson --- some things to do

Asked by Adam Sweeney

Is it possible to run sikuli scripts on a CI environment like hudson? I've tried multiple things with little luck.

********** Adam Sweeney finally succeeded by doing this: (see comment # 10)

For making the service interactive, to use desktop and clipboard, etc. In Administrative Tools-> Services, right click the Apache Tomcat 6 service that corresponds to Hudson -> Properties. Go to the “Log On” tab, and there’s a checkbox you need to enable “Allow service to interact with desktop”. Restart the service after you have enabled this.

------------------------------------------------------------------------------

Question information

Language:
English Edit question
Status:
Solved
For:
SikuliX Edit question
Assignee:
No assignee Edit question
Solved by:
RaiMan
Solved:
Last query:
Last reply:
Revision history for this message
RaiMan (raimund-hocke) said :
#1

the Sikuli scripts, you post on Hudson to be run as tests, have to run on a machine with a real screen and have to fulfill the minimum requirements to run a Sikuli script: the libs folder must be available and in the system path.

Then a command like
java -jar path-to-sikuli-script.jar path-to-your-script.sikuli

should run the script. There might be necessary some more JVM specific parameters, but to get a script starting that's all.

Revision history for this message
RaiMan (raimund-hocke) said :
#2

sorry, forgot that path-to-java/jre6/bin has to be in system path too on Windows systems.

Revision history for this message
Adam Sweeney (asweeney) said :
#3

Hey RaiMan Thanks for your responses,

I put C:\sikuli\libs;C:\Program Files\java\jre6\bin in my PATH at the very beginning.

That seems to work, but only when i do it through the hudson view (. When i specify the java -jar path.jar path.sikuli through the hudson command i get

C:\.hudson\jobs\SikuliTemplate\workspace>java -jar c:\Sikuli\sikuli-script.jar c:\sikuli\hudsontest.sikuli
Exception in thread "main" Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Sikuli\sikuli-script.jar\Lib\sikuli\__init__.py", line 1, in <module>
  File "C:\Sikuli\sikuli-script.jar\Lib\sikuli\Sikuli.py", line 20, in <module>
java.lang.UnsatisfiedLinkError: C:\WINDOWS\Temp\tmplib\VisionProxy.dll: Can't find dependent libraries

 at java.lang.ClassLoader$NativeLibrary.load(Native Method)

 at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)

 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1699)

 at java.lang.Runtime.load0(Runtime.java:770)

 at java.lang.System.load(System.java:1003)

 at com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(NativeLoader.java:44)

 at org.sikuli.script.Finder.<clinit>(Finder.java:28)

 at java.lang.Class.forName0(Native Method)

 at java.lang.Class.forName(Class.java:169)

 at org.python.core.SyspathJavaLoader.loadClass(SyspathJavaLoader.java:107)

 at java.lang.ClassLoader.loadClass(ClassLoader.java:248)

 at org.python.core.Py.findClassEx(Py.java:817)

 at org.python.core.packagecache.SysPackageManager.findClass(SysPackageManager.java:133)

 at org.python.core.packagecache.PackageManager.findClass(PackageManager.java:28)

 at org.python.core.packagecache.SysPackageManager.findClass(SysPackageManager.java:122)

 at org.python.core.PyJavaPackage.__findattr_ex__(PyJavaPackage.java:137)

 at org.python.core.PyObject.__findattr__(PyObject.java:869)

 at org.python.core.imp.import_name(imp.java:771)

 at org.python.core.imp.importName(imp.java:806)

 at org.python.core.ImportFunction.__call__(__builtin__.java:1232)

 at org.python.core.PyObject.__call__(PyObject.java:367)

 at org.python.core.__builtin__.__import__(__builtin__.java:1202)

 at org.python.core.imp.importFromAs(imp.java:884)

 at org.python.core.imp.importFrom(imp.java:860)

 at sikuli.Sikuli$py.f$0(C:\Sikuli\sikuli-script.jar\Lib\sikuli\Sikuli.py:209)

 at sikuli.Sikuli$py.call_function(C:\Sikuli\sikuli-script.jar\Lib\sikuli\Sikuli.py)

 at org.python.core.PyTableCode.call(PyTableCode.java:165)

 at org.python.core.PyCode.call(PyCode.java:18)

 at org.python.core.imp.createFromCode(imp.java:326)

 at org.python.core.util.importer.importer_load_module(importer.java:109)

 at org.python.modules.zipimport.zipimporter.zipimporter_load_module(zipimporter.java:161)

 at org.python.modules.zipimport.zipimporter$zipimporter_load_module_exposer.__call__(Unknown Source)

 at org.python.core.PyBuiltinMethodNarrow.__call__(PyBuiltinMethodNarrow.java:47)

 at org.python.core.imp.loadFromLoader(imp.java:451)

 at org.python.core.imp.find_module(imp.java:408)

 at org.python.core.PyModule.impAttr(PyModule.java:109)

 at org.python.core.imp.import_next(imp.java:637)

 at org.python.core.imp.import_name(imp.java:746)

 at org.python.core.imp.importName(imp.java:806)

 at org.python.core.ImportFunction.__call__(__builtin__.java:1232)

 at org.python.core.PyObject.__call__(PyObject.java:367)

 at org.python.core.__builtin__.__import__(__builtin__.java:1202)

 at org.python.core.__builtin__.__import__(__builtin__.java:1185)

 at org.python.core.imp.importAll(imp.java:904)

 at sikuli$py.f$0(C:\Sikuli\sikuli-script.jar\Lib\sikuli\__init__.py:1)

 at sikuli$py.call_function(C:\Sikuli\sikuli-script.jar\Lib\sikuli\__init__.py)

 at org.python.core.PyTableCode.call(PyTableCode.java:165)

 at org.python.core.PyCode.call(PyCode.java:18)

 at org.python.core.imp.createFromCode(imp.java:326)

 at org.python.core.util.importer.importer_load_module(importer.java:109)

 at org.python.modules.zipimport.zipimporter.zipimporter_load_module(zipimporter.java:161)

 at org.python.modules.zipimport.zipimporter$zipimporter_load_module_exposer.__call__(Unknown Source)

 at org.python.core.PyBuiltinMethodNarrow.__call__(PyBuiltinMethodNarrow.java:47)

 at org.python.core.imp.loadFromLoader(imp.java:451)

 at org.python.core.imp.find_module(imp.java:408)

 at org.python.core.imp.import_next(imp.java:635)

 at org.python.core.imp.import_name(imp.java:746)

 at org.python.core.imp.importName(imp.java:806)

 at org.python.core.ImportFunction.__call__(__builtin__.java:1232)

 at org.python.core.PyObject.__call__(PyObject.java:367)

 at org.python.core.__builtin__.__import__(__builtin__.java:1202)

 at org.python.core.__builtin__.__import__(__builtin__.java:1185)

 at org.python.core.imp.importAll(imp.java:904)

 at org.python.pycode._pyx2.f$0(<string>:1)

 at org.python.pycode._pyx2.call_function(<string>)

 at org.python.core.PyTableCode.call(PyTableCode.java:165)

 at org.python.core.PyCode.call(PyCode.java:18)

 at org.python.core.Py.runCode(Py.java:1204)

 at org.python.core.Py.exec(Py.java:1248)

 at org.python.util.PythonInterpreter.exec(PythonInterpreter.java:172)

 at org.sikuli.script.ScriptRunner.runPython(ScriptRunner.java:52)

 at org.sikuli.script.ScriptRunner.runPython(ScriptRunner.java:92)

 at org.sikuli.script.SikuliScript.main(SikuliScript.java:102)

java.lang.UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: C:\WINDOWS\Temp\tmplib\VisionProxy.dll: Can't find dependent libraries

C:\.hudson\jobs\SikuliTemplate\workspace>exit 1
Finished: FAILURE

I saw the error, but i thought it might be different because its only when i run that command through the hudson web interface. Not the hudson view

Revision history for this message
RaiMan (raimund-hocke) said :
#4

It seems you have taken the zipped version and put it into c:\Sikuli (since you use the jar-reference c:\Sikuli\sikuli-script.jar).

In the system path on the machine running Sikuli (however it is started) there must be (does not matter where) c:\Sikuli\libs, so the C:\WINDOWS\Temp\tmplib\VisionProxy.dll (which is moved there by Sikuli's initialization) can find the native libs (OpenCV in this case).

This was what I meant, when saying in my first answer: ... have to fulfill the minimum requirements to run a Sikuli script: the libs folder must be available and in the system path.

Revision history for this message
Adam Sweeney (asweeney) said :
#5

I've added c:\sikuli\libs to my system path, i mentioned it above. I'm not using the zip download, i used the .exe download, just using that command (java -jar path.jar path.sikuli) because when it works, i want to pull the test from svn.

Revision history for this message
RaiMan (raimund-hocke) said :
#6

Sorry, 2Fast2Furious ;-) and have no idea, how Hudson works in real life.

Only to be sure: When talking about modifying system path, I am talking about Windows System Settings -> Extended Settings -> Environment Variables -> User Path.

Can it be, that in this case where it fails, Hudson creates an environment on it's own and does not use the system path? If so, somewhere in Hudson there must be a possibility to configure the environment for this.

Can you check the contents of PATH in this moment?

If you want to do these checks from inside the script using the respective Python functions
(e.g. import os; print os.environ['PATH']),
use this command to start your script:

java -cp c:\Sikuli\sikuli-script.jar org.python.util.jython c:\sikuli\hudsontest.sikuli\hudsontest.py

which starts the Jython interpreter accessing the contained .py file. So when running your script, no Sikuli initialization (and hence no library not found errors) takes place, until later in the script "from sikuli.Sikuli import *" is processed (needed in this case to access the Sikuli features).

Revision history for this message
Best RaiMan (raimund-hocke) said :
#7

since rc2 there is a new environment option for Windows to specify, where the Sikuli installation is located, if it is not installed in the standard place: %SIKULI_HOME%

see Details: http://sikuli.org/docx/faq/010-command-line.html#running-sikuli-script-jar-from-command-line

This might help, since the problem arises because during the Sikuli init phase the respective dll's are copied to a temp folder in your error case, which should normally not be.

Revision history for this message
Adam Sweeney (asweeney) said :
#8

Haha getting prepped for Fast 5?

I checked the path while it was running and it returned everything i setup, as for running the command

java -cp c:\sikuli\sikuli-script.jar org.python.util.jython c:\hudsontest.sikuli\hudsontest.py

I get an import problem when i run it through the command line of the system(expected)
and through the hudson interface i get the unsatisfiedlinkerror again.

I also specified the home of sikuli (SIKULI_HOME) in hudson, to the location, but it didn't do anything different.

Anyways the team here said to just worry about it locally and look at hudson a bit later.

Revision history for this message
RaiMan (raimund-hocke) said :
#9

Ok, I slow down now to zero - couldn't do anything else anyway ;-)

Come back, if you have new information - I will do also if I come across anything.

Revision history for this message
Adam Sweeney (asweeney) said :
#10

Apparently we had to do this:

For making the service interactive, to use desktop and clipboard, etc. In Administrative Tools-> Services, right click the Apache Tomcat 6 service that corresponds to Hudson -> Properties. Go to the “Log On” tab, and there’s a checkbox you need to enable “Allow service to interact with desktop”. Restart the service after you have enabled this.

Works now :)

Revision history for this message
Adam Sweeney (asweeney) said :
#11

Thanks RaiMan, that solved my question.

Revision history for this message
RaiMan (raimund-hocke) said :
#12

Thanks for the information.

I will put a reference to your comment in the top.

Revision history for this message
Robert Batusek (robert-batusek) said :
#13

Hello,

I have the same problem and I was not able to solve it even by setting the jenkins service interactive. Our setup:

Our hudson/jenkins installation is not a physical machine, but a virtual machine running somewhere. The only way to log in is via a remote desktop. If I set the jenkins service interactive, it informs the remote desktop session that it has something to display on screen. If I click on it and watch the jenkins screen the whole time, the Sikuli tests run curretly. But if I close the remote desktop session to jenkins or even cover it by another window, our Sikuli script stops recognizing images, probably because they disappeared from the screen.

I wanted to ask Adam: how is your Hudson installation - is it a physical machine with a screen attached to it with a user still logged in?

Or do you have any other ideas, how this could be solved?

Revision history for this message
Adam Sweeney (asweeney) said :
#14

Hi Robert,

Yeah our hudson installation is on a physical machine, with a user always logged in. Its the only way as far as i know to get it to work. We've had problems in the past where if someone remote logged into the machine, then it would log the user out, and we'd have to log back into the physical machine.

As far as I know Sikuli always needs the focus of the screen to be what your testing. If you do want some behind the scenes type of testing, I'd recommend Selenium.

Revision history for this message
Anton Redozubov (anton-x8) said :
#15

Is it possible to run Sikuli on remote machine while hudson runs on virtual server?

Revision history for this message
RaiMan (raimund-hocke) said :
#16

@ Anton

--1. Sikuli must be installed together with Java 6 on the machine where you want to run Sikuli scripts (or use the Sikuli API somehow e.g. from a Java program)

--2. Sikuli needs access to a real monitor (on headless machines Sikuli does not work), while a script is running (this usually means, that someone has to be logged on at this machine).

--3. With some prereqs it is possible to run Sikuli scripts against a VNC session (see respective topics here in the board).

Revision history for this message
Anton Redozubov (anton-x8) said :
#17

Thank you.
I understand all this 3 requirements.
But I want to know is it possible to start remote Sikuli tests via Hudson.
I have VPS with Hudson and ordinary desktop with Sikuli.

Revision history for this message
RaiMan (raimund-hocke) said :
#18

@ Anton
I am not the Hudson expert ;-)
As far as I understand this system, it is possible to start and manage test runs on different remote machines. If this e.g. works with some SSH like channel and command line scripts on these remote machines, it should be rather easy, starting Sikuli scripts using the command line possibilities.

The most compact version:
java -jar sikuli-script.jar some-script.sikuli

where all the file references have to be adapted to your paths and Sikuli's prereqs must be fulfilled.

Revision history for this message
Anton Redozubov (anton-x8) said :
#19

Thank you.
Will try.

Revision history for this message
jaffer (jaffer) said :
#20

I have not installed tomcat as a service and set all prerequisites for SIKULI.
Still seeing failure in hudson CI server environment but passing locally.
Let me know if u guys have any ideas on how to proceed further.

env variables set :
JAVA_HOME=C:\Program Files\Java\jdk1.7.0_25
JRE_HOME=C:\Program Files\Java\jre7 ( 32 bit JRE )
SIKULI_HOME=C:\SikuliX
PATH=C:\Program Files\Java\jre7\bin;C:\SikuliX\libs;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
 at org.openqa.selenium.support.PageFactory.instantiatePage(PageFactory.java:140)
 at org.openqa.selenium.support.PageFactory.initElements(PageFactory.java:66)
 at com.owler.ui.sikuli.SignUpActivationTest.beforeClass(SignUpActivationTest.java:24)
 at org.openqa.selenium.support.PageFactory.instantiatePage(PageFactory.java:131)
 ... 36 more
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\rspp\AppData\Local\Temp\tmplib\Win32Util.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
 at java.lang.ClassLoader$NativeLibrary.load(Native Method)
 at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
 at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843)
 at java.lang.Runtime.load0(Runtime.java:795)
 at java.lang.System.load(System.java:1061)
 at com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(NativeLoader.java:44)
 at org.sikuli.script.Win32Util.<clinit>(Win32Util.java:19)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:190)
 at org.sikuli.script.Env.getOSUtil(Env.java:91)
 at org.sikuli.script.ScreenHighlighter.init(ScreenHighlighter.java:180)
 at org.sikuli.script.ScreenHighlighter.<init>(ScreenHighlighter.java:293)
 at org.sikuli.script.Screen.initBounds(Screen.java:105)
 at org.sikuli.script.Screen.<init>(Screen.java:117)
 at com.owler.ui.sikuli.SignUpActivation.<init>(SignUpActivation.java:18)
 ... 41 more
... Removed 39 stack frames

Revision history for this message
jaffer (jaffer) said :
#21

Please let me know if any workarounds as iam running sikuli as java code from maven project.

Revision history for this message
RaiMan (raimund-hocke) said :
#22

@jaffer
looks like version RC3
true?

Revision history for this message
jaffer (jaffer) said :
#23

@Raiman,

Thanks for quick reply.

I am currently using below build which is working fine in local windows but fails to work in remote hudson server and i have active RDP connection opened to hudson windows server.

Tomcat using zipped file version instead of windows service.

SikuliX Setup Build: 1.0.1 2SEP2013172831

Revision history for this message
RaiMan (raimund-hocke) said :
#24

@jaffer

--1. SIKULI_HOME=C:\SikuliX is for RC3 (SIKULIX_HOME=C:\SikuliX for 1.0.1+) …
… but is not needed when I suppose, that the sikuli-java.jar (recommended jar for use with Java programming) is in C:\SikuliX (setup folder) and stays there forever.

--2. mixup with RC3 …
… you seem to have some mixup with RC3 artifacts and settings. (a Win32Util.dll is from RC3, 1.0.1 has WinUtil.dll)
When you want to use version 1.0.1 you should take care that at least in any environment settings nothing points to the RC3 installation (usually in ProgramFiles - where version 1.0.1 should never be!)

--3 using 32-Bit all with Java 64-Bit …
… is not possible (at time of crash a 64-Bit JVM is active.
This is no problem with version 1.0.1 since it will export the correct library set depending on the bitness of the JVM to the folder libs in the folder containing sikuli-java.jar.

Take care: The only thing that should be done manually to avoid silly error messages: have the libs folder in the setup folder in system path at runtime (which seems to be already the case with c:\SikuliX\libs).

To get more debugging info at Sikuli startup (Sikuli classes loaded the first time in your case), have a JVM runtime parameter as:
-Dsikuli.Debug=3

Revision history for this message
jaffer (jaffer) said :
#25

Still getting the same exception with below settings.
1) removed SIKULI_HOME.
2) added "-Dsikuli.Debug=3" to the maven command line.

Revision history for this message
jaffer (jaffer) said :
#26

clean -Dtestngfile=testng-qe -Dsikuli.Debug=3 -DappURL=<Url> test -X

Revision history for this message
RaiMan (raimund-hocke) said :
#27

... and what about the debug output?

Revision history for this message
jaffer (jaffer) said :
#28

java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
 at org.openqa.selenium.support.PageFactory.instantiatePage(PageFactory.java:140)
 at org.openqa.selenium.support.PageFactory.initElements(PageFactory.java:66)
 at com.owler.ui.sikuli.SignUpActivationTest.beforeClass(SignUpActivationTest.java:24)
 at org.openqa.selenium.support.PageFactory.instantiatePage(PageFactory.java:131)
 ... 36 more
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\rspp\AppData\Local\Temp\tmplib\Win32Util.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
 at java.lang.ClassLoader$NativeLibrary.load(Native Method)
 at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1957)
 at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1882)
 at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1843)
 at java.lang.Runtime.load0(Runtime.java:795)
 at java.lang.System.load(System.java:1061)
 at com.wapmx.nativeutils.jniloader.NativeLoader.loadLibrary(NativeLoader.java:44)
 at org.sikuli.script.Win32Util.<clinit>(Win32Util.java:19)
 at java.lang.Class.forName0(Native Method)
 at java.lang.Class.forName(Class.java:190)
 at org.sikuli.script.Env.getOSUtil(Env.java:91)
 at org.sikuli.script.ScreenHighlighter.init(ScreenHighlighter.java:180)
 at org.sikuli.script.ScreenHighlighter.<init>(ScreenHighlighter.java:293)
 at org.sikuli.script.Screen.initBounds(Screen.java:105)
 at org.sikuli.script.Screen.<init>(Screen.java:117)
 at com.owler.ui.sikuli.SignUpActivation.<init>(SignUpActivation.java:18)
 ... 41 more
... Removed 39 stack frames
Click to show all stack frames

Revision history for this message
RaiMan (raimund-hocke) said :
#29

This is not the Debug output and you still have a mixup of 1.0.1 and RC3:
as already mentioned: Win32Util.dll is from RC3

BTW: what does that mean:
Tomcat using zipped file version ????

Revision history for this message
jaffer (jaffer) said :
#30

http://tomcat.apache.org/download-60.cgi
we have both Windows Service Installer and zip file format for installation of tomcat.
I am using zip file format which doesn't require windows service.

Revision history for this message
RaiMan (raimund-hocke) said :
#31

ok, understood.

... but what about the Sikuli debug output?

Revision history for this message
jaffer (jaffer) said :
#32

running maven command with -Dsikuli.Debug=3 is not helping me with debug output.
can you help me in how to capture the debug output.

Revision history for this message
RaiMan (raimund-hocke) said :
#33

then you are not running version 1.0.1 in the tomcat environment.

Revision history for this message
jaffer (jaffer) said :
#34

Workarounds to be followed for Sikuli :
-------------------------------------------
1a) Turn tomcat as windows service interactive, to use desktop and clipboard, etc.
In Administrative Tools-> Services, right click the Apache Tomcat 6 service that corresponds to Hudson -> Properties.
Go to the “Log On” tab, and there’s a checkbox you need to enable “Allow service to interact with desktop”.
Restart the service after you have enabled this.
1b) 32 bit JDK as JAVA_HOME
eg: C:\Program Files (x86)\Java\jdk1.7.0_51
2) C:\SikuliX\libs to PATH variable
3) Interactive Services Detection service should be running.
4) Session Isolation
switch to session 0 to see tests running
rundll32 winsta.dll,WinStationSwitchToServicesSession
logged in session to back to user session
rundll32 winsta.dll,WinStationRevertFromServicesSession

Revision history for this message
jaffer (jaffer) said :
#35

currently running sikuli with above steps introduces 2 additional problems
1) RDP connection gets disconnected automatically after every sikuli test gets over.
2) automatic switch from batch command to session 0 to see test run fails which inturn blocks taking automatic screenshots.
So What is the supported sikuli version to run with hudson CI server on windows env where tomcat is running from zipped format.