CSC/ECE 517 Spring 2017/oss M1706: Difference between revisions
No edit summary |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
===Description=== | ===Description=== | ||
This purpose of this project is provide additional testing infrastructure for the | This purpose of this project is provide additional testing infrastructure for the Servo OSS project. "[https://github.com/servo/servo/wiki/Design Servo] is a project to develop a new Web browser engine. The goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely. | ||
In particular, this project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Intermittent failures frequently occur but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolved the most prevalent issues. | In particular, this project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Intermittent failures frequently occur but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolved the most prevalent issues. | ||
| Line 44: | Line 44: | ||
====Views==== | ====Views==== | ||
===Round 2=== | |||
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user. | |||
build a HTML front-end to the service that queries it using JS and reports the results in a useful manner (linking to github, sorting, etc.) - For this we should be able to repurpose the testing webpages that we built in the first round. Polishing these up and giving them the required JS request mechanism should suffice. | |||
I suppose these two last steps are the full integration of this product into the servo pipeline. | |||
make filter-intermittents command record a separate failure for each intermittent failure encountered - This should be interesting as we'll have to fork the servo repo as this is handled in a different part than the actual service for tracking the intermittent failures. | |||
propagate the required information for recording failures in saltfs - Again this appears to be in the seperate testing_commands file in the larger servo repo. | |||
===Important Links=== | ===Important Links=== | ||
Latest revision as of 02:11, 6 April 2017
Description
This purpose of this project is provide additional testing infrastructure for the Servo OSS project. "Servo is a project to develop a new Web browser engine. The goal is to create an architecture that takes advantage of parallelism at many levels while eliminating common sources of bugs and security vulnerabilities associated with incorrect memory management and data races." Servo can be used through Browser.html, embedded in a website, or natively in Mozilla Firefox. It is designed to load web pages more efficiently and more securely.
In particular, this project is a request from the Servo OSS project to reduce the impact intermittent test failures have on the software. Intermittent failures frequently occur but are normally ignored during continuous integration. The frequency of each intermittent failure signature, though not currently logged, would be useful in allowing developers to identify and resolved the most prevalent issues.
Tasks to be completed
Current Implementation
UML Diagram
Proposed Design
TASK 1 -
TASK 2 -
Design Pattern Used
Features to be added
Testing Plan
Files Changed and Added
Models
Controllers
Views
Round 2
The first request is to add the ability to query the service by a date range, to find out which failures were most frequent. Given the fail_date is included in the addition call as an ISO date string, we should be able to build a function to query this date using standard date functions and a range given from the user.
build a HTML front-end to the service that queries it using JS and reports the results in a useful manner (linking to github, sorting, etc.) - For this we should be able to repurpose the testing webpages that we built in the first round. Polishing these up and giving them the required JS request mechanism should suffice.
I suppose these two last steps are the full integration of this product into the servo pipeline.
make filter-intermittents command record a separate failure for each intermittent failure encountered - This should be interesting as we'll have to fork the servo repo as this is handled in a different part than the actual service for tracking the intermittent failures.
propagate the required information for recording failures in saltfs - Again this appears to be in the seperate testing_commands file in the larger servo repo.
Important Links
Link to Github repository : https://github.com/adamw17/csc517ossproject
Link to Pull request : The contact for this project asked us to create an entirely new repository. A pull request is not applicable.