Confirmed users
1,927
edits
QA/Execution/Web Testing/Lab: Difference between revisions
Jump to navigation
Jump to search
→Architecture
No edit summary |
|||
| Line 24: | Line 24: | ||
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. | 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. | 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. | ||