|
|
| Line 1: |
Line 1: |
| == Goals ==
| | This page has been moved to https://wiki.mozilla.org/QA/Execution/Web_Testing/Flame_Buildout |
| === Short Term ===
| |
| * build a small capacity (>=8 Flames) automation system running b2gperf and subset of UI tests per gaia commit, flashing gecko periodically from b2g-inbound
| |
| * ETA: July 21st
| |
| | |
| === Long Term ===
| |
| * build a higher-capacity (>30 Firefox OS Flames) pool of phones hooked up to mozpool, fully-capable (SIM cards, Wi-Fi, SD cards, etc.), reporting to treeherder
| |
| * ETA: Q3
| |
| | |
| === Jenkins URL: [http://jenkins1.qa.scl3.mozilla.com/ http://jenkins1.qa.scl3.mozilla.com/] ===
| |
| | |
| <bugzilla>
| |
| {
| |
| "blocks": "1019792",
| |
| "status": ["NEW", "REOPENED", "ASSIGNED"]
| |
| }
| |
| </bugzilla>
| |
| | |
| === Etherpad ===
| |
| https://etherpad.mozilla.org/b2g-per-checkin-smoketest
| |
| | |
| == Architecture ==
| |
| [[File:Flame-setup.png]]
| |
| | |
| Pictured above is the planned architecture for automated testing on Flames. Although each Jenkins node will execute only one job at a time, for redundancy each has multiple, probably two or three, Flames attached via USB. It is [[ReleaseEngineering/Mozpool|Mozpool]]'s job to both prep a Flame and verify that it is fully functional before passing it back (via its serial number) to the node's job. If a Flame is nonfunctional, Mozpool will try the next one, as long as there are Flames available.
| |
| | |
| Note that the Flames are seated in controllable power harnesses, which will act as relays the relays do in the original Panda-based Pulse system.
| |
| | |
| This isn't terribly efficient, since many of the phones will sit idle, but at the moment a dedicated USB connection to the Jenkins node is required, so using a single pool of Flames isn't yet viable. Perhaps some sort of USB-network bridge might make this possible in the future.
| |
Latest revision as of 17:59, 4 July 2014