#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Resultdb Component: resultdb | Keywords: ----------------------+----------------------------------------------------- To continue development and AutoQA/ResultDB integration we need to have ResultsDB filled with relevant data for testing. Later on we might need to put already existing result data into ResultDB when it becomes operational.
All the past data sits in the mailing list archives, so let's create a script that will parse the stored mbox file and input the data into ResultDB using it's input API.
#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Resultdb Component: resultdb | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by tflink):
This is similar to something that was on my personal list of stuff to hack on and I'm wondering if a slightly different implementation could kill 2 birds with 1 stone.
I wanted something that would re-create a job locally for the purposes of debugging. My plan was to input an autotest job number and the script would find the test logs and parse them to create a manifest of the files needed and the command line to run.
Any thoughts on whether this would fit in with the code to parse mbox files?
#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Resultdb Component: resultdb | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by vhumpa):
I am making a script that will obtain all the e-mails out of the Mailman web-archive for the REmail [1] project. The script will basically concentrate all e-mails it can find there and concentrate them in a single MBox file. This is handy for one of REmail's data source modules and I wonder whether this could also be of some use in AutoQA/ResultsDB, which has the same kind of archive for its results list [2].
I am thinking this could be useful to create an input for the script we talk about in this ticket. Or do we have a nice access to the MBox files of all the results, directly on some production machine, that could be used?
I know AutoQA has other priorities right now, I am just thinking of killing two flies with a single newspaper while working on REmail (my thesis project).
[1] http://code.google.com/p/r-email/ [2] https://fedorahosted.org/mailman/listinfo/autoqa-results
#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Resultdb Component: resultdb | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by vhumpa):
I've been working on this in last couple of days and the script seems to be ready for the most part. Now I am trying to figure out how exactly to use the API. The input part is naturally focused on being used on the fly while the tests are being done. Now the goal is to use the same API to mass input test results from the autoqa-results list. Looks like I need to simulate each run for every result, if am I not mistaken.
In the basic, it seems to me that calling start_testrun() and end_testrun() with values parsed out of the emails is the way. This will likely produce an incorrect information about the testrun time, as it will use the current time, right? Is there a way to override this (Joza)? In any case, please prove me wrong if I intend to use the API sequence wrong or I'd not include some necessary information this way.
#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Resultdb Component: resultdb | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by jskladan):
You're right. Start_testrun() / end_testrun() combo should be sufficient for your need. And yes, it will use the current time (no way to override it in the current API, and I don't think that there ever will be. A simple workaround might be storing start/end time in keyvals.
#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: new Priority: major | Milestone: Resultdb Component: resultdb | Resolution: Keywords: | ----------------------+----------------------------------------------------- Comment (by vhumpa):
Good! The original timestamps will likely be needed so the keyvals sound like the place to store it. Sorry this got delayed a little bit with my transition to Desktop. I plan to finish this hopefully this weekend so that you can build on it further.
#313: ResultsDB: Script to parse the mailing-list and fill the resultsDB ----------------------+----------------------------------------------------- Reporter: vhumpa | Owner: vhumpa Type: task | Status: closed Priority: major | Milestone: Resultdb Component: resultdb | Resolution: fixed Keywords: | ----------------------+----------------------------------------------------- Changes (by jskladan):
* status: new => closed * resolution: => fixed
autoqa-devel@lists.fedorahosted.org
-
fedora-badges