This is a joint, webqa/amo project. We want to set up ci.mozilla.org so that it can run amo's selenium tests. This will require downloading the read-only version of this repo: https://github.com/mozilla/moz-grid-config The repo contains the lastest selenium jar file and a file with certificate exceptions for the browser. Once moz-grid-config is downloaded, selenium can be run from within the moz-grid-config directory with the following command: java -jar lib/selenium-server-standalone-2.17.0.jar -firefoxProfileTemplate firefoxprofiles/certificateExceptions/ The support needed for this will be to periodically do a git pull on moz-grid-config when the selenium jar is updated.
Summary: Run selenium server and set up windows vm on ci.mozilla.org for running selenium tests with jenkins → Run selenium server for running selenium tests with jenkins
fox2mike, to clarify, we're asking to get java installed on that box and for that java -jar command to run as a daemon. It looks like the github page has instructions on how to set that up. Once we have the service up I can help Marlena create a new Jenkins job.
Using the moz-grid-config repository just for the Selenium library feels overkill to me. I would suggest downloading the latest jar from http://code.google.com/p/selenium/downloads whenever a new version is available. The AMO Selenium tests currently use the WebDriver API, which does not use the certificate exceptions profile. I believe that a good alternative is to get a dedicated VM running a Selenium Grid hub, and set a Windows VM up as a node. This means we can execute the tests in the same way we currently do against our Selenium Grid in MV, and gives us the ability to scale up as needed.
Would it make sense just to poke some holes in the firewall so that ci.mozilla.org can run tests by talking to the existing selenium grid?
(In reply to Kumar McMillan [:kumar] from comment #3) > Would it make sense just to poke some holes in the firewall so that > ci.mozilla.org can run tests by talking to the existing selenium grid? Yes, we're already trying to get that, over in bug 712946. I've cc:d you.
Based on the security concerns of relaxing the firewall rules, it might make sense to just have a VM running the Selenium server within same network.
(In reply to Dave Hunt (:davehunt) from comment #5) > Based on the security concerns of relaxing the firewall rules, it might make > sense to just have a VM running the Selenium server within same network. Dave, What exactly will this involve? Infra might not be happy about running something without it being puppetized, so we might have to work on getting this up and running with puppet.
The minimum here is a Windows box with the latest Firefox release installed and running a standalone Selenium server (java library). This would allow the CI to direct tests to the Selenium server. If we needed extra capacity, we would also have another box running a Selenium Grid hub (same jar dependency as standalone) so that it could proxy requests to the Selenium node running on the Windows VM (and any others that may be set up). This solution would probably ideally use our moz-grid-config project for launching the hub/node. These could be implemented at different times, the former to get us up and running and the latter to allow us to scale up for running additional WebQA tests or more browser instances in parallel.  https://github.com/mozilla/moz-grid-config
So it looks like the options here are: 1. ci.m.o in phx1 talks to qa-selenium in mtv1 (bug 712946) 2. ci.m.o in phx1 talks to one or more windows VMs in a DC (this bug) 3. move qa-selenium + minis to a DC and talk to them there The first is disliked because flows from DMZ into corp are generally discouraged. The second is disliked because that Windows VM wouldn't be running Puppet (did I get that right?!) The third is disliked because these are Apple hardware, ergo not lights-out manageable. Given those options, I think 2 is the least distasteful in the short term, but I may be missing context. Let's try to make that work quickly enough to not have to move sm-selenium01 (bug 726820). If that doesn't work, then the minis would find themselves in good company in scl3, since releng is moving 80-some-odd of them there (these are rackmount, unibody minis -- I racked 'em in mtv1). Would either option fit in the sjc1-evacuation timeframe? And, given the above, should bug 712946 be WONTFIXed again?
I believe this is going to be taken care of in bug 693544. What does it mean that the VMs wouldn't be running Puppet? They are pretty basic and just have a few things installed (Java, Ant, Git, various Firefox versions). What would be involved in 'puppetizing' these and how can we help?
From discussion in IRC, this bug has come around to want the same thing as bug 693544, so I'm dup'ing it there. This should get the necessary technological prereqs for AMO and WebQA to collaborate on jenkins tests.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 693544
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.