QA/Execution/Web Testing/Flame Buildout

Goals

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/

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Etherpad

https://etherpad.mozilla.org/b2g-per-checkin-smoketest

Architecture

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 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.