CSC/ECE 517 Spring 2017/OSS M1706 Tracking intermittent test failures over time: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
This is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made was for a Flask service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker will store information regarding a test that fails intermittently and also provide means to quickly query for tests that have failed.
This is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The [https://github.com/servo/servo/wiki/Tracking-intermittent-failures-over-time-project request] made is for a Flask service using [https://en.wikipedia.org/wiki/Python_(programming_language) Python 2.7]. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.


== Scope ==
== Scope ==
The intermittent test failure tracker  initial steps included
The intermittent test failure tracker  initial steps include:
* Build a flask service
* Build a flask service
* Use a JSON file to store information
* Use a JSON file to store information
* Test file, platform, test machine (builder), and related Github pull request number are required parameters
* Request/create required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
* Allow querying the store results given a particular test file name.
* Allow querying the store results given a particular test file name
* Use the known intermittent issue tracker as an example of a Simple flask server  
* Use the known intermittent issue tracker as an example of a Simple flask server  


Subsequent steps included
Subsequent steps include:
* Add ability to query the service by a date range, to find out which were occurred the most often
* Add ability to query the service by a date range, to find out which were occurred the most often
* Build an HTML front-end to the service that queries using JS and reports the results
* Build an HTML front-end to the service that queries using JS and reports the results
** Links to github
** Links to GitHub
** Sorting
** Sorting
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Make [https://github.com/servo/servo/blob/master/python/servo/testing_commands.py#L508-L574 filter-intermittents] command record a separate failure for each intermittent failure encountered
* Propgate the rqeuired information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]
* Propogate the required information for recording failures in [https://github.com/servo/saltfs/issues/597 saltfs]


== Design ==
== Design ==
Line 22: Line 22:


===== Saving a Test =====
===== Saving a Test =====
The servo build agent will call a webhook inside the test tracker. The webhook will then call a handler that contains any business logic necessary to transform the request. Finally the handler would persist the request into the db, in this case a json file. This flow can be seen in the graph below.
The servo build agent calls a webhook inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.


<pre>
<pre>
Line 41: Line 41:


== Implementation ==
== Implementation ==
The implementation was entirely influenced by the request, the servo team had clearly defined what the service should do and how it would be made.
The implementation is entirely influenced by the request, the servo team clearly defines what the service should do and how it would be made.


=== Data model ===
=== Data model ===
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.
The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.


{| class="wikitable"  
{| class="wikitable"  
Line 66: Line 66:
| number
| number
| Integer
| Integer
| The github pull request number
| The GitHub pull request number
|-
|-
| fail_date
| fail_date
Line 73: Line 73:
|}
|}
=== Datastore ===
=== Datastore ===
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] was used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.
To store the intermittent test failures, a library called [https://tinydb.readthedocs.io/en/latest/ TinyDB] is used. This library is a native python library that provides convenient [https://en.wikipedia.org/wiki/SQL SQL] command like helpers around a [https://www.w3schools.com/js/js_json_syntax.asp JSON] file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.


=== Flask Service ===
=== Flask Service ===
Line 90: Line 90:
== Submission ==
== Submission ==


The work has been started in a new github repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When servo developers are ready, the project will be pulled in to the servo project on github.
The work has been started in a new GitHub repo located [https://github.com/adamw17/csc517ossproject/tree/832969c1cf01d94be340731c744854c25fdbb441 here]. When servo developers are ready, the project will be pulled in to the servo project on GitHub.

Revision as of 01:05, 23 March 2017

This is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. The request made is for a Flask service using Python 2.7. The intermittent test failure tracker stores information regarding a test that fails intermittently and also provides means to quickly query for tests that have failed.

Scope

The intermittent test failure tracker initial steps include:

  • Build a flask service
  • Use a JSON file to store information
  • Request/create required parameters: Test file, platform, test machine (builder), and related GitHub pull request number
  • Allow querying the store results given a particular test file name
  • Use the known intermittent issue tracker as an example of a Simple flask server

Subsequent steps include:

  • Add ability to query the service by a date range, to find out which were occurred the most often
  • Build an HTML front-end to the service that queries using JS and reports the results
    • Links to GitHub
    • Sorting
  • Make filter-intermittents command record a separate failure for each intermittent failure encountered
  • Propogate the required information for recording failures in saltfs

Design

Application Flow

Saving a Test

The servo build agent calls a webhook inside the test tracker. The webhook then calls a handler that contains any business logic necessary to transform the request. Finally the handler persists the request into the db, in this case a json file. This flow can be seen in the graph below.

                    +---------------------------------------------+
                    |       Intermittent Test Failure Tracker     |
                    |                                             |
+--------------+    | +-----------+      +---------+    +------+  |
|              |    | |           |      |         |    |      |  |      +--------+
|    Servo     |    | |           |      |         |    |      |  |      |        |
|    Build     +------>  webhook  +------> handler +---->  db  +--------->  json  |
|    Server    |    | |           |      |         |    |      |  |      |  file  |
|              |    | |           |      |         |    |      |  |      |        |
+--------------+    | +-----------+      +---------+    +------+  |      +--------+
                    |                                             |
                    +---------------------------------------------+

Implementation

The implementation is entirely influenced by the request, the servo team clearly defines what the service should do and how it would be made.

Data model

The model for an intermittent test is defined mostly by the request with a few additions to help with querying in later steps of the OSS request.

Name Type Description
test_file String Name of the intermittent test file
platform String Platform the test failed on
builder String The test machine (builder) the test failed on
number Integer The GitHub pull request number
fail_date ISO date (String) Date of the failure

Datastore

To store the intermittent test failures, a library called TinyDB is used. This library is a native python library that provides convenient SQL command like helpers around a JSON file to more easily use it like a database. The format of the JSON file is simply an array of JSON objects, making the file easily human readable.

Flask Service

Flask is a microservice framework written in Python. A flask service is a REST (representational state transfer) API that maps URL and HTTP verbs to python functions. Some basic examples of flask routes:

 @app.route('/')
 def index():
   return 'Index page'
 
 @app.route('/user/<username>')
 def show_user(username):
   return db.lookup(username)

The first method returns 'index page' at the root URL. The second method accepts a URL param after user and returns the user from a database.

Submission

The work has been started in a new GitHub repo located here. When servo developers are ready, the project will be pulled in to the servo project on GitHub.