Odd one here that I have not seen before. I decided to load a local instance of Jenkins on my Win 10 Laptop. The service is up and running and everything is building fine but when it tries to open chrome, I see the below in the log. I can execute it from Visual Studio and Command Line with no issues.
Research has mentioned lowering the chromedriver version so I tried with no luck. I have only run jenkins in master/agent config so maybe this has to do with jenkins being run on local host?
Starting ChromeDriver 77.0.3865.40 (f484704e052e0b556f8030b65b953dce96503217-
refs/branch-heads/3865#{#442}) on port 7797
Only local connections are allowed.
Please protect ports used by ChromeDriver and related test frameworks to
prevent access by malicious code.
[1571096148.894][WARNING]: Timed out connecting to Chrome, retrying...
Additional things I have tried....
Creating a new user with all permissions to the jenkins dir
Running the service as the new user
OK I gave up running as a service. I copied the Jenkins.war file to the the directory I wanted. In this case, D:\Jenkins and then I executed:
D:\Jenkins>Java -jar Jenkins.war
This reloaded the Jenkins install. I added msbuild/tfs plugins and I am now running jenkins from the command line vs as a service. Everything is working now.
Just a work around but it may help someone else out.
Related
So the concept is like this -
I would like to run the selenium server .jar file on a remote windows machine.
Then connect to it via the default port (:4444), open browser and navigate to a URL of my choosing.
I have everything working except the part of running the selenium server through robot.
This keyword works as far as I can tell (until the open browser keyword) -
Start Selenium Server
&{client} = Return Internal Host
Connect Environment Machine Windows ${client}
start process java -jar ${/}SeleniumServer${/}selenium-server-standalone-3.141.59.jar alias=seleniumserver
process should be running seleniumserver
open browser http://example.com/example.html chrome None http://1.1.1.1:4444/wd/hub
BUT, when I try to connect to the selenium server I get the following error -
"No connection could be made because the target machine actively refused it"
It seems like the process either does not run or runs for a short amount of time then closes.
What am I missing here?
If I manually start the server on the client, everything works. It opens the browser and does whatever I need. (manually running the java -jar selenium*.jar on the cmd)
But when I run this Start process keyword, that should keep the process running in the background, I get connection refused. Any Ideas?
Another piece of information that might be useful - The selenium server should throw an error if trying to run it twice on the same machine (because of the used port bind 4444).
When running the keyword shown above, while there is a selenium server up and running on the target machine, the test still passes for some reason. Not sure if it is even running the process as intended but the "process should be running" keyword seems to pass.
Thanks!
Im running chrome headless through chromedriver and selenium via python.
I've run into the following issue both on Mac and Linux.
Im starting chrome as follows:
if self.headless:
options.headless = True
options.add_argument("--headless")
if self.debug_port:
logging.info(f"Setting up remote debugging on port {self.debug_port}")
options.add_argument(f"--remote-debugging-port={self.debug_port}")
options.add_argument(f"--remote-debugging-address=0.0.0.0")
If I connect to http://localhost:9222 from another headed instance of chrome I can see the list of sessions and connect to it seamlessly. At which point i have a window opened up with a screencast of the remote session and the dev console.
Here's that successful example:
When I connect to http://192.168.1.194:9222 I get the list of sessions just fine and upon selecting one the dev console opens but it doesn't start the websocket connection to ws://192.168.1.194 so the screencast and remote debugging capabilities are not available.
Here's that failed example:
I've captured har files and uploaded them here if you want to take a look
Using the following steps I was able to debug remotely. However the screencast functionality did not work. Ultimately that's what I needed so this is only a 50% solution in my case.
So, as noted above in the comments, what's blocking remote debugging from working is that the chrome debugger links out to https://chrome-devtools-frontend.appspot.com/..... and passes a value of ws://192.168.1.194 for the websocket parameter. Any browser will inherently block this, based on it being mixed content - i.e: https + ws
What's needed here is to run the chrome dev tools frontend on a http server
and direct your chrome instance to that server instead of the appspot instance.
Solution Steps
1 Install depot_tools (pre-requisite for building)
https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up
2 Checkout the devtools-frontend repo
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#checking-out-source
3 Build chrome devtools frontend
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#build
4 Start the devtools-frontend http server
https://github.com/ChromeDevTools/devtools-frontend/blob/master/docs/workflows.md#running-in-hosted-mode
5 Run 2 instances of chrome and use one to debug the other
5.1 Start first instance of chrome headless
...with remote debugging enabled. See the python way in the question above or do it from the command line with the same arguments
5.2 Start a second instance of chrome
...using a different user data dir --user-data-dir=<some-path>
5.3 Navigate to http://192.168.1.194:9222
Use whatever the IP address of the first chrome instance is and the port that you chose.
5.4 Create a link to the local dev server
The 2nd instance of chrome will now be showing you links to debug each of the open tabs of the 1st instance. However the links will still to go https://chrome-devtools-frontend.appspot.com/..... You'll need to copy n paste the link you want and replace the hostname with the hostname of the devtools frontend that you started in step 4
Walla!!
If you figure out how to get the screencast working please comment below! 🙏
N.B:
I also tried using the npm run server command in the devtools frontend but for some reason that server didn't work at all ¯\_(ツ)_/¯
I have a GoCD server that I plan on running my selenium test suite on. This machine is a Linux machine. So.. I set up selenium on a windows machine. The key problem I am having is that when running as a service, or a scheduled task, the selenium hub does not launch IE.
If I remote desktop into the machine, run the jar manually from command line, the browser launches in my RDP session and the tests all pass. If I install it as a service (With permissions to interact with the desktop!) the driver appears to run, but the content never loads.
So if you have an answer, please remember:
The grid works for all browsers with an interactive desktop session open.
Without an interactive desktop session, Chrome and Firefox tests still pass (in headless mode).
I am using no selenium nodes, I am only using the standalone jar (not running as hub or node, just running the tests standalone.
I am using version 3.14 of both selenium standalone and IEDriverServer.exe
I know that tons of people do automated IE tests with selenium, but how do they do it with Hub on windows?
I've tried literally every options setting I can see to try to phinigel a way to get it to work, but it's just not having it.
I also tried running as a scheduled task rather than a service, no dice there either.
This is the precise error the IETests are presenting:
Oct 09, 2018 1:15:12 PM org.openqa.selenium.remote.ProtocolHandshake createSession
INFO: Detected dialect: W3C
org.openqa.selenium.TimeoutException: Expected condition failed: waiting for value to contain "sign-in.host.com". Current value: "null" (tried for 10 second(s) with 500 milliseconds interval)
at org.openqa.selenium.support.ui.WebDriverWait.timeoutException(WebDriverWait.java:113)
at org.openqa.selenium.support.ui.FluentWait.until(FluentWait.java:283)
I used to have issues with IE selenium tests on a VM in azure. What i noticed was that while RDP to the machine everything worked fine but when i closed the session all tests failed.
What i ended up doing was leaving a logged in console session after every RDP closing.
After adding a trigger on session log off i run a powershell script with the following:
Tscon 1 /dest:console
This keeps an active desktop session and my tests on IE pass.
I'm having trouble running some Selenium tests on a Jenkins Slave. 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 slave is a virtual machine (Windows Server 2012 R2). The Jenkins Slave is Connected via JNLP agent. The slave 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 slave 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!
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.
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:
Hope this helps someone!
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. ;)
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);
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.
We have a CI setup using bamboo where one job was to run our automation, it checks out our Automation Solution from a repository, and run it using NUnit runner where it contains tests using selenium webdriver and some unit tests. It runs unit tests(not using webdriver commands) just fine, but not the webdriver tests.
We are sure that the solution is being checkout correctly because we can run the test using the command line referencing the created local repository, including tests that uses webdriver using the command below:
C:\pathToNUnitConsole\nunit-console C:\pathToCreatedLocalRepositoryInTheServer\NUnitTest.dll -include=FirefoxBrowserTest
We can see that the bamboo job never launched a browser, and we are getting test failure for not seeing browser elements. Also, we are getting error as we see in the logs:
10-Apr-2015 13:19:49 http://10.215.12.28:15871/cgi-bin/blockpage.cgi?ws-session=587410860
10-Apr-2015 13:20:42 JavaScript error: resource://gre/modules/CertUtils.jsm, line 168: NS_ERROR_ABORT: Certificate issuer is not built-in.
I don't know if this is your problem, but it sounds very similar to an issue I had trying to get NUnit runner to run tests built in SpecsFor.MVC, which is a wrapper that deals with instantiating an IIS Express instance, deploying a target web application to known location, then using Selenium/Chrome Driver to run the tests against the web app.
The problem I had was trying to run the Bamboo remote agent as a windows service. The Local Service account was not able to access the interactive desktop. Also, changing the service to run as a specific user account still failed, as the service was not allowed access to the user's isolated Session0.
I could login as that test user and run the test from the command line no trouble, but I couldn't get it to run when initiated by the remote agent windows service.
I eventually fixed it by using AlwaysUp (not a plug. I'm sure other similar solutions are available). This allowed me to set the machine running the tests to always log in as the test user on startup, would automatically restart the bamboo remote agent if it was closed for some reason and most importantly, to give the service access to the user's isolated session0.
Hope that might give you a few clues...