Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Why Sauce Connect and BrowserStack Local are on this image #65
Sauce Connect is documented in the README but will be extracted into his own docker image eventually since it doesn't belong here really, same with BrowserStack tunnel.
noVNC support was removed after version 2.52.0g and re-added again later on so can be found on recent versions.
First of all, great work. My request for documentation is more on the "uses" of sauce connect. The Readme shows the parameters, but not how you would use it with your tests. I have a Sauce Labs account, and would be happy to contribute, but I don't understand what SC does in your image.
When I use SC in my tests I create a RemoteWebDriver Uri which points to ondemand.saucelabs.com. If I use SC in your GRID is it supposed to send jobs to SauceLabs?
Thank you again for the great work
So what is the purpose of SC/BrowserStack in your GRID? What would it be used for?
Also, I have found the Video recording functionality very useful in tracking down random tests failures. I have a test suite of 70 tests, and 2 or 3 different tests would fail each time. It was difficult to track down, so I modified your GRID to create a separate video for each test, and could play back the one that failed. Do you already have plans on adding this functionality to your source? If not I can contribute, but I don't know if my method is the best approach. I have a separate script reading the Selenium logs for "Starting ChromeDriver" and "delete session". This kicks off start-video and stop-video with different names. It creates video-1, video-2, and so on. I'm working on passing the test name through capabilities so I can actually name the video file the same as the test.
Shouldn't be used, is a proof of concept.
Great idea! though the proper implementation wouldn't be parsing log files IMO but rather write a Selenium proxy handler that adds this custom logic, see:
The logic to parse the capatibilites could also live there, in that grid-plugin java code.
You could potentially include logic to forward test to Sauce Labs when the capabilities are not satisfied by docker-selenium, see:
And also, imagine that for every new session a new docker-selenium container is created and disposed when the session ends, that would be lovely, make docer run / docker stop transparent to the users by invoking docker from that same grid-plugin using some docker java bindings, e.g. https://github.com/docker-java/docker-java
I would love to see any of that functionality added :)
changed the title from
Why Sauce Connect and BrowserStack Local are on this image
May 5, 2016
Just to jump in, all the desired features mentioned here are already part of Zalenium, except the Sauce Connect and BrowserStack local (which are coming soon in a release in the near future).
Would be cool if you can try it since we need some more feedback from external users.