From Fedora Project Wiki

No edit summary
No edit summary
Line 15: Line 15:
I have also started to work on a proof-of-concept frontend [5], which will allow us to create test plans (like Package Update Acceptance Testplan [6]), using mediawiki pages to define the testplan's requirements [7], [8] (this will be covered in more detail further in the text).
I have also started to work on a proof-of-concept frontend [5], which will allow us to create test plans (like Package Update Acceptance Testplan [6]), using mediawiki pages to define the testplan's requirements [7], [8] (this will be covered in more detail further in the text).


[1] https://fedorahosted.org/pipermail/autoqa-results/
 
[2] https://fedoraproject.org/wiki/AutoQA_resultsdb_schema
= Links =
[3] https://fedoraproject.org/wiki/AutoQA_resultsdb_API
 
[4] https://www.assembla.com/code/resultsdb/git/nodes?rev=devel
* [1] https://fedorahosted.org/pipermail/autoqa-results/
[5] https://www.assembla.com/code/resultsdb_puatp/git/nodes?rev=master
* [2] https://fedoraproject.org/wiki/AutoQA_resultsdb_schema
[6] https://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan
* [3] https://fedoraproject.org/wiki/AutoQA_resultsdb_API
[7] http://fedoraproject.org/wiki/QA:Test_Plan_Metadata_Test_Page
* [4] https://www.assembla.com/code/resultsdb/git/nodes?rev=devel
[8] https://fedoraproject.org/wiki/User:Jskladan/Sandbox:Package_Update_Acceptance_Test_Plan_Metadata
* [5] https://www.assembla.com/code/resultsdb_puatp/git/nodes?rev=master
* [6] https://fedoraproject.org/wiki/QA:Package_Update_Acceptance_Test_Plan
* [7] http://fedoraproject.org/wiki/QA:Test_Plan_Metadata_Test_Page
* [8] https://fedoraproject.org/wiki/User:Jskladan/Sandbox:Package_Update_Acceptance_Test_Plan_Metadata

Revision as of 13:13, 6 April 2011

What is ResultsDB

ResultsDB is a database, in which we'll store results of tests executed by the AutoQA framework.

Motivation behind ResultsDB

At the moment, all the results are stored on the autoqa-results mailing list [1]. Although this is not really a bad system for storing the results, searching for some particular result (even as simple query as "All results for foobar-1.3-fc15") is not really comfortable. ResultsDB's main purpose is not really to store the data, but to provide easy access to the results via some simple querying API.

This means, that using the ResultsDB as dabase backend, many 'frontends' can be created. Be it simple tools which will just aggregate most recent results for specified package (maybe a table inside koji/bodhi info pages), some statistical tool for gathering fail/pass ratio of *insert test name of your choice* for given Fedora release, etc.

Current state

From development point of view, there is quite well-defined database schema [2], 'input' API [3], and proof-of-concept TurboGears2 application [4], implementing these two.

I have also started to work on a proof-of-concept frontend [5], which will allow us to create test plans (like Package Update Acceptance Testplan [6]), using mediawiki pages to define the testplan's requirements [7], [8] (this will be covered in more detail further in the text).


Links