CODEWITHSUNDEEP
seleniumnunitselenium-chromedrivercruisecontrol.net
Sunnx
Sunnx

Reputation: 81

Chrome Driver Error using Selenium and NUnit Console: Unable to Discover Open Pages

All of my Selenium tests are getting failed only when running it through Cruisecontrol.net, whereas running it through command line using the same user (on which cc.net runs) seems fine.

Running on cc.net is also resulting in opening up more than 30~40 chromedriver processes and which eventually is resulting in "Unable to Discover Open Pages". Running on a commandline is fine and has only 1 chromedriver process.

So far I have tried : --no-sandbox option, Power settings changes on that user, Updated Chromedriver to latest version & restarted and rebooted the cc.net service and server

Any help is highly appreciated....

Upvotes: 0

Views: 1198

Answers (3)

Benjamin Baumann
Benjamin Baumann

Reputation: 4065

I also had the same issue. The (ugly) workaround I set up was :

  • open a session on the CI Server
  • run the ChromeDriver.exe from the command line
  • leave the session open

Now selenium webdriver can connect to the chromedriver listening on its specific port and having a graphic session to interact with.

Upvotes: 0

Cosmin
Cosmin

Reputation: 2394

I had the exact same issue with MSTest and Microsoft Test Agents and below is the solution for how I managed to fix it. However, I don't know CruiseControl, so I have no idea if you can install it to run as a process.

Basically the Test Agent was installed as a service, and every process launched from a Windows (NT) Service runs on Session 0, invisible to a logged on user.

Chrome is trying to move away from Session 0 and you can find further references of this here (comment 21 in the link below, but actually the whole thread is a good read in respect to this subject): https://bugs.chromium.org/p/chromium/issues/detail?id=615396#c21

Now, to fix this, there are several options available: Download a Canary build from Chrome but this is not recommended as this is only a temporary fix. Chrome devs are saying that in the near future Session 0 will no longer be available with Chrome (and ChromeDriver).

The best solution is to have MS Test Agent installed as a process so that all applications are visible to the logged in user. More details can be found here: https://msdn.microsoft.com/en-us/library/ee291332.aspx

Another option for this is to have the settings below added as Chrome arguments, however I didn't test with those using the Test Agent as a Windows Service, so I don't know if it's working or not, but I can confirm that it's working with the Test Agent as a process.

var chromeOptions = new ChromeOptions();
chromeOptions.AddArguments("test-type");
chromeOptions.AddArguments("--disable-extensions");
chromeOptions.AddArguments("no-sandbox");
var driver = new ChromeDriver(chromeOptions);

As for the multiple instances of ChromeDriver open, again the issue was for MSTest, so maybe NUnit is different, but my issue was that the tests were failing in the TestInitialize method. When this happens, TestCleanup is no longer called. It seems that TestCleanup gets executed only when TestMethod fails and having my driver.Quit(); statement in TestCleanup I ended with the memory depleted on the test server because of the number of ChromeDriver instances open.

Upvotes: 1

Simon Laing
Simon Laing

Reputation: 1214

I've had issues in the past running some tasks via CCNet, those tasks are typically ones which require the creation of a window in the context of MS windows.

That means any process, or child process, which tries to create a new (visible) window may misbehave. Console windows appear to be fine as they share a common instance (maybe?). From experience and testing this is a MS windows 'issue' not localised to CCNet.

I've encountered this with selenium as it's typically driving a browser (which itself - attempts to - show a window). I have had success with PhantomJs driven via selenium in CCNet (when running as a limited service)

If the windows service is set to run as SYSTEM then you can allow the service to "interact with the desktop". This allows the service to create new windows under the service account. However in my experience this has only worked when a user session is attached*; disconnecting from the session returns to the non-working behaviour.

* This is when windows prompts the user to connect to the SYSTEM service window station to see the interactive content (the windows). It may be only supported on windows server, and I think I saw it only when connecting via Remote Desktop to the server.

I couldn't find an elegant solution to this problem, beyond invoking the process via PSEXEC onto a server/session which behaved as expected and consistently.

Upvotes: 1

Related Questions