I’ve managed to install the current version of robot and imagehorizonlibrary in a container, let’s call this the robot container.
I’ve installed the PythonRemoteServer on the target VM which also contains the GUI application. Both the Target VM and the robot container is running on a linux host.
I’ve ran the example project that comes with the PythonRemoteServer and it does work if you enable host network for the container. However, when running the test script for the GUI application I am getting some errors.
FYI, I’m issuing the robot command from the robot container as such:
One of the issue was pyautogui not having the DISPLAY variable. I assume it was trying to use the DISPLAY variable from the container as I was executing it from there. However, I have set the DISPLAY to 192.168.121.78:1 while enabling xhost + on the target. This allowed me to proceed but I received this error:
01 Help Tab :: Execute command on remote machine and getting their output a...
Open Help Tab | FAIL |
FileNotFoundError: [Errno 2] No such file or directory: 'gnome-terminal': 'gnome-terminal'
Also teardown failed:
Several failures occurred:
1) NotImplementedError: "scrot" must be installed to use screenshot functions in Linux. Run: sudo apt-get install scrot
2) TypeError: 'NoneType' object is not iterable
In the test case, I am trying to open up a terminal:
I managed to installed which to fix the scrot issue. Regarding the gnome-terminal issue, it looks like upon execution the target VM pulls up a terminal but it is a terminal from the robot container and not from the target VM itself.
Does robot not run these test cases on the server side?
how does the screenshot folder and it’s contents get onto the container?
FYI I suspect the error FileNotFoundError: [Errno 2] No such file or directory indicates that ImageHorizionLibrary can’t find the images or screenshot folder, if you are sure the files are on the robot container, pay attention to the section Reference image names of the ImageHorizionLibrary documentation (it’s tripped me up before)
Understanding what you are trying to achieve
Q1: If understand correctly you want to run the test on the container but you want it to test the application that runs on the VM?
Q2: Why not run the Application you want to test on the same container or VM as you are running Robot Framework?
I know there are some robot framework libraries, i’m not sure if all of them can, I suspect ImageHorizionLibrary can’t but I don’t know for sure?
If ImageHorizionLibrary can be run against a remote machine it may require ImageHorizionLibrary and robot framework installed on the remote machine (your VM?) and it may also require the image folder to be on the remote machine (your VM?) as well but I don’t know enough to be sure.
gnome-terminal is a command to launch a terminal, it is not the name of the screenshot folder.
I mount the screenshot folder inside the container using bind volumes.
A2. The application requires a GUI and I was interested to not install the entire robot framework inside the VM running the application. Yes, If I install robot framework along with the application in the VM it does work and executes the test case. However, we are trying to not perform an intrusive test where robot gets installed on the payload VM.
A3. That’s a good though. I’ll have to dive into the ImageHorizonLibrary. Curiosity took over me and I decided to install the gnome-terminal inside the container and set the DISPLAY to 192.168.121.78:0 and when I reran the test I did see a terminal getting pulled up on the target VM. But it is the shell terminal of the robot container… and NOT the target VM’s terminal. This is a problem because further along the test case it’s suppose to open the GUI application but it can’t because it’s not the correct shell.
That’s actually not surprising and is actually a feature of the *nix X display that you could utilise, let me explain:
If you setup an X display driver on the container (or use a VM instead of the container if you prefer) then your test could ssh (SSHLibrary) to the test VM with the application installed, within the ssh session you set your display variable to the X display of your robot container/vm and then launch the application. the application will be running on the vm but displayed on the robot contaier’s display so that ImageHorizion can “see” it and interact with it.
If you do it like this you would have one container/vm with RF, ImageHorizion, etc, the application vm can change from release to release and the only change is the IP address of the target VM to ssh to, this can easily be handled with the variable that’s set on the command line when starting robot framework that you already have.