QA/Execution/Web Testing/Flame Buildout

From MozillaWiki
Jump to: navigation, search

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

Flame-setup.png

Pictured above is an architecture diagram for automated testing on Flames for a sample system with two nodes and two devices per node. Flames are attached to test machines via USB and assigned to its Mozpool instance.

Because we need not just a free Jenkins executor but a working and prepped Flame, the Jenkins scheduler contacts a central Mozpool instance that routes requests to a local Mozpool instance that has an available device (all Mozpool instances share a single database). The local Mozpool instance flashes the Flame and verifies that it is fully functional before passing its serial number and executor to the scheduler, which then instructs the node to be begin the job. If a Flame is nonfunctional, the Jenkins master will choose another or block until one becomes available.

Note that the Flames are seated in controllable power harnesses, which will act as the relays do in the original Panda-based Pulse system.

Retrieved from "https://wiki.mozilla.org/index.php?title=QA/Execution/Web_Testing/Flame_Buildout&oldid=1000651"