QA/Automation/Projects/Mozmill Shared Modules/On Demand Testing: Difference between revisions

QA/Automation/Projects/Mozmill Shared Modules/On Demand Testing (view source)

Revision as of 02:35, 12 August 2011

203 bytes removed , 12 August 2011

→‎The Process after Phase I

Gmealer

canmove, Confirmed users

2,041

edits

@@ Line 47: / Line 47: @@
 # From the test plan, create a configuration file including the desired builds, platforms, and locales.
 # Run a single script that reads the configuration file, automatically downloads the desired builds, and stages them in the disk share.
-# Run a single script that uses ssh to log into each target platform machine and executes the existing update testing script.
+# Run a single script that uses pulse to kick off a process on each target platform machine and executes the existing update testing script.
 # Look in brasstacks (our automation result reporting framework) for the update test results as they land.
-We have already moved to putting the results in brasstacks. The balance of Phase I requires creation of two scripts:
-* The staging script
-* The execution script
 ===The Staging Script===
-The staging script should take as input a configuration file containing a list of all desired platforms, builds, and locales.
+The staging script takes as input a configuration file containing a list of all desired platforms, builds, and locales.
-It should also take an option which is the root of the staging file system.
-The script will expand the configuration file's lists into a comprehensive list of desired builds, and download into the staging area.
+The script expands the configuration file's lists into a comprehensive list of desired builds, and downloads into the staging area.
 ===The Execution Script===
-The execution script should take as input a configuration file containing a list of target execution platforms.
+The execution system consists of two parts, a test pusher and a test listener.
-The script will iterate through the list, logging into each platform and running the current update testing script. The current script already knows how to look in the staging area.
+The test pusher defines the branch, update channel, and optionally the platform to be tested. The test listener runs on each desired platform; when a push for all platforms or for the selected platform is received, it launches the existing update test scripts.
-Login details will be handled via public/private key setup rather than name/PW to avoid having to write a secure way to encapsulate login info.
+The existing update test scripts consume the directory tree created by the staging script to perform the desired total test run.