Changes

Jump to: navigation, search

Auto-tools/Projects/OrangeFactor

4,297 bytes added, 17:36, 27 May 2011
REST API
https://developer.mozilla.org/en/QA/Fixing_intermittent_oranges
 
== REST API ==
 
The War on Orange site pulls its data from a REST API. Other applications can hook into this to get the raw orange data.
 
The API root is at http://brasstacks.mozilla.com/orangefactor/api/. Parameters are passed via the query string, eg. ?key1=value1&key2=value2. Example: http://brasstacks.mozilla.com/orangefactor/api/count?startday=2011-05-21&endday=2011-05-27&tree=mozilla-central
 
All returned data is in JSON format.
 
=== bybug ===
 
Provides a date-indexed list of oranges, with bug numbers, along with minimal details of each bug.
 
Parameters:
* startday: Mandatory. In ISO format, e.g. 2011-05-27.
* endday: Mandatory. Also in ISO format.
* bugid: Optional. Return orange data for this bug only.
* tree: Optional. Return information about this tree only. Defaults to mozilla-central. Pass "all" for orange data on all trees.
* type: Optional. Return information for this build type only. Must be "opt" or "debug". Defaults to none (both build types).
 
Returns an object with two properties:
* oranges: An object with dates as properties, e.g. data['oranges']['2011-05-27']. Each property is another object with orange data for the day, with the following properties:
** orangecount: total number of oranges for that day, e.g. 54.
** testruns: number of test runs that day, e.g. 24. The "Orange Factor" is orangecount/testruns.
** oranges: details of the oranges that occurred that day. It is an array of objects, each one having these simple properties:
*** buildtype
*** date
*** starttime
*** timestamp
*** platform
*** branch
*** machinename
*** test
*** bug
*** revision
* bugs: An object with bug ids as properties. Each bug in the above list of oranges is represented here. The information is gathered via pulse and thus is quicker to access than querying Bugzilla. Only a few basic properties are available; for more detailed info, you will have to consult Bugzilla:
** id
** status
** summary
 
=== count ===
 
Returns a date-indexed summary of orange data.
 
The parameters are the same as for bybug. The returned data is also the same, except that the 'bugs' property is not returned, and the array of orange details (data['oranges'][<date>]['oranges']) is empty. This is a faster way to get just the summarized numerical data for, e.g., Orange Factor calculations.
 
=== bugdetails ===
 
Returns minimal details for one or more bugs.
 
The only parameter is "bugid", which takes a bug id or a comma-separated list of bug ids.
 
Returns the same data as the "bugs" property of the bybug returned data.
 
=== testrun ===
 
Returns information on one or more test runs.
 
Parameters:
 
The request can be made in one of two fashions. To get information about only one test run,
 
* starttime: Unix timestamp of the run's start time.
* machine: Hostname of the test machine.
 
Or to get information on several,
 
* runs: a comma-separated list of timestamps and machines, in the form <timestamp>|<machine>,<timestamp>|<machine>, eg testrun?runs=1297070365|talos-r3-leopard-012,1295484366|talos-r3-xp-037
 
Returns an object with properties in the form '<timestamp>|<machine>' (regardless of which parameter format was used). Each property has an array of matching test runs, with these properties:
 
* tree
* passed/failed/todo: the number of tests in each category; may be missing for testruns that never completed due to crashes, etc
* elapsedtime: number of seconds it took for the testrun to complete
* suitename
* builder: the buildbot builder string
* machine: the machine name
* cmdline: the command line used to invoke the test
* buildtype: opt or debug
* platform: buildbot platform string
* date: date the testrun was run, YYYY-MM-DD
* buildid: the buildbot buildid used to run the test
* revision: the hg revision used to run the test
* testfailure_count: the number of failing tests in this testrun.
* testrunerrors: an array of errors that could not be pinned to a specific test; these are usually memory leaks or crashes that occur at the end of a testrun. these errors are not included in 'testfailure_count'
* testfailures: an array of testfailures which is testfailure_count in length; each member of this array has two keys:
* test: the name of the test that failed
* failures: a list of failures that occurred
* logurl: URL to the complete test log.
Confirm
1,927
edits

Navigation menu