canmove, Confirmed users
2,041
edits
QA/Test Automation/2010-12-01: Difference between revisions
→Triggered software updates (Geo)
(→Others) |
|||
| Line 35: | Line 35: | ||
==Triggered software updates (Geo)== | ==Triggered software updates (Geo)== | ||
* | * Proposed structure: | ||
** Trigger comes from somewhere on build landing, contains current build id | |||
*** Open question: Pulse vs. Email from Releng? In discussions now on both sides. | |||
** Polling script on VM catches trigger | |||
** Current build downloaded and saved off for next trigger. | |||
** Queuing mechanism (directory full of semaphores or a flat file) for queuing landed builds | |||
*** May not be needed for initial PoC as builds don't typically come frequently enough to queue. This would be an edge case handler. | |||
** Build saved off from last trigger will be updated and compared to expected build id. | |||
** Initial reporting to brasstacks, possiblly email on failures | |||
** Initial version for trunk, en_US only. Still targeting multi-platform. | |||
* Things already there | |||
** Script to update a build and do some basic heuristics for testing exists. | |||
* Things needed now | |||
** Update test script needs to be able to take a particular build id for verification | |||
** Trigger being decided upon between QA, RelEng, and Christian Legnitto (Pulse) | |||
*** Eventually we want to be on Pulse, is unknown now whether it's sufficiently mature. | |||
*** Go/no-go on Pulse to be made no later than next week, possibly as early as Friday. | |||
*** Overall structure the same regardless. | |||
** Polling script | |||
** Queuing mechanism (? see above) | |||
* Things needed eventually | |||
** RelEng wants to do this in their infrastructure eventually if at all possible. | |||
** If not possible, we'll need a way to report directly back to RelEng | |||
** Not there yet, though. For now want to run it on our side to make sure of robustness before putting in critical path. | |||
* Complications | |||
** If we can't get per-platform notifications, may have to add what amounts to a multiplexer | |||
*** Multiplexer would take one final notification and then notify all the VMs. | |||
*** I'd rather not have to do this (it's complicated, delays testing, and possibly introduces deadlocks) so am seeking per-platform notifications. | |||
==Mozmill Crowd Extension (Henrik)== | ==Mozmill Crowd Extension (Henrik)== | ||