Setting display resolution for Selenium tests on virtual machine as Jenkins agent
Asked Answered
F

5

9

I'm having trouble running some Selenium tests on a Jenkins agent. To be specific, the display resolution that is used to run the tests is too small, causing some of the tests to fail.

To check the display resolution, we log the display height and width to the console, using:

driver.manage().window().maximize();
System.out.println("Window height: " + driver.manage().window().getSize().getHeight());
System.out.println("Window width: " + driver.manage().window().getSize().getWidth());

This returns:

Window height: 784
Window width: 1040

which seems like a very strange resolution to me. The desired resolution is 1920 x 1080.

The server that is used as a agent is a virtual machine (Windows Server 2012 R2). The Jenkins agent is Connected via JNLP agent. The agent has the service running with Log On As "Local System" with the "Allow service to interact with desktop" option enabled.

So far we've tried a number of things like:

  • Connecting to agent VM using RDP and disconnecting to leave session open with desired display resolution
  • Using powershell to set the display resolution
  • Setting the default display resolution in the VM configuration
  • Setting the window dimensions using Selenium
  • And more...

All of these didn't resolve the issues. Suggestions are very welcome!

Fatherly answered 14/3, 2017 at 11:56 Comment(5)
You can probably set the display size: driver.manage().window().setSize(new Dimension(1920, 1080))Beast
@Kishan Patel, that does not have any effect in this case. I think it's not possible to set a size in that way that is bigger than the display size of the server.Fatherly
I am using ubantu right now so can't actually test it. however, I tried following exe to set the resolution before start of test. Separate script from test script. and it worked for me. can you give it a try. tools.taubenkorb.at/change-screen-resolutionAlaniz
@GaurangShah Tried this executable and all other alternatives that are mentioned on the page but unfortunately none of them have the desired result.Fatherly
Nothing seems to work with this issue...Melena
F
8

Finally managed to fix these issues after realizing that Jenkins does not necessarily need to run the slaves as a windows service. To start the slave, the JNLP agent can be downloaded from Jenkins and copied to the server. When running the JNLP file, you can select for the option to install the slave agent as a service.

Jenkins slave agent

Previously we had this option selected, that's why the slave was running as a service. After stopping and removing the service, we ran the JNLP file again and made sure to not select the option.

The solutions suggested that included disconnecting the remote desktop session and leaving the session open with a large resolution didn't work when running the slave as a service. They do work however when running the slave in the default way.

Make sure that the remote desktop session is not ended after a certain period of time: Session timeout properties

Hope this helps someone!

Fatherly answered 15/3, 2017 at 10:14 Comment(0)
E
4

Based on my experience with this you can't solve this problem programmatically. Your tests will run on the resolution which was used last time when you physically accessed this VM's display. For example, if I open VM on my big screen monitor and maximize it, tests will run on that resolution. But if I open it on my laptop screen and close RDP connection, tests will run on that smaller screen size. I know it sounds strange, but I really couldn't find better solution. :D So now I must be careful to maximize VM display on my bigger screen before I close VM. You will probably dislike this answer, but remember it when you find yourself out of other solutions. ;)

Earsplitting answered 14/3, 2017 at 12:43 Comment(2)
I experimented with this but it didn't help. Logged in to the VM with RDP and disconnected the session. The jenkins slave service is running as Local System user so connecting to the VM with my own user would not have any effect. Even when forcing the service to run with my own user account it didn't use the resolution from the RDP session.Fatherly
Ok, my slave was running on local user account, not on local system, sorry it didn't help.Earsplitting
M
1

Solution that worked for me is to run Chrome in a 'headless' mode (without GUI). It works with Jenkins Agent running as a service, when GUI is not available. Here is the code sample of the web driver initialization:

var options = new ChromeOptions();
options.BinaryLocation = @"C:\Program Files\Google\Chrome\Application\chrome.exe";
options.AddArgument("Headless");
options.AddArgument("window-size=1920,1080");

driver = new ChromeDriver(@"<path>\Selenium.WebDriver.ChromeDriver.2.37.0\driver\win32", options);
Merrick answered 8/9, 2021 at 8:31 Comment(0)
C
0

I've been experienced the same issue. My seleniumn tests run under jenkins slave installed as windows service, using "Local System" account with "Allow service to interact with desktop" option enabled in windows 7. Some test cases were always failed due to incorrect display resolution.

I logged in to the console of the windows VM (EXSI Server + VMware Fusion), changed the resolution to 1400x900, and restart the windwos VM. Everything works well now.

Computation answered 23/11, 2017 at 6:24 Comment(0)
B
0

For any folks looking to handle the same issue but with the Selenium Node hosted on Vsphere with Windows10 virtual machines, the following steps were required:

  1. Setup an automatic login so that the task running the selenium node can run with a user signed in. (to setup windows automatic login see: this article from Microsoft)

  2. Setup a scheduled task that, on login of user specified for automatic login, will run the following commands with highest priviledges.

    cd "C:\Program Files\VMware\VMware Tools"

    VMwareResolutionSet.exe 0 1 , 0 0 [x] [y]

(where "x" = desired width in pixels and "y" = desired height) For more information on the second step see this article from vmware

Basilius answered 7/11, 2023 at 20:36 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.