Now with the add-ons test-run in place we will have to make sure that all necessary data from the tests will be send to the report server.

Move of Mozmill related project bugs to newly created components. You can filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.

This patch adds the details of the add-on under test to the report. We only need the id, name, and version. All the other information we will retrieve via the Add-ons Manager within the tests in the future.

Comment on attachment 521933 [details] [diff] [review] Patch v1 + def get_text(element): I wouldn't put this as a sub-function as it really is outside of the function scope (getting details for the addon) and serves its own purpose(getting the text for an xml minidom node whereas better xml parsers would already have a function for this). + details = { + 'id' : 'n/a', + 'name': 'n/a', + 'version': 'n/a', + } Maybe use None for the keys or a non-true singleton class that stringifies to 'n/a' Other than that, looks good and much more robust than the way we do it in mozprofile. I haven't tested, but IIRC you have :) r=me

We might want to upstream some/all of this to mozprofile. The way we parse install.rdf is fairly error-prone and I'd like to make it better (that said, abict it works on all use-cases in the wild that we've tried in its current incarnation). We might want an addons module within mozprofile where we put this sort of thing. This patch goes some ways towards implementing a (basic) RDF parser. Maybe we should go that way since we've already rolled so much of our own and we're nervous about taking dependencies (on e.g. a full rdf parser). Its my opinion that good software development practice is to consume software, but understand that in the current state of (e.g.) mozilla-central, this isn't as trivial as would necessarily make it convenient

(In reply to comment #3) > Comment on attachment 521933 [details] [diff] [review] > Patch v1 > + def get_text(element): > I wouldn't put this as a sub-function as it really is outside of the function > scope (getting details for the addon) and serves its own purpose(getting the It's the same as for the get_namespace_id method. So you say we should move both out to a separate module?

(In reply to comment #5) > (In reply to comment #3) > > Comment on attachment 521933 [details] [diff] [review] > > Patch v1 > > + def get_text(element): > > I wouldn't put this as a sub-function as it really is outside of the function > > scope (getting details for the addon) and serves its own purpose(getting the > > It's the same as for the get_namespace_id method. So you say we should move > both out to a separate module? Its hard for me to assess what exactly should be done, not really knowing the plans for this code. Ideally this sort of thing would go in mozprofile and you could just consume it. That aside, they should at least (IMHO) be free-standing functions since they don't rely on the state of the "closure" you're in and they are genuinely standalone methods.

Implemented latest review comments and created new rdf_parser module.

Comment on attachment 522490 [details] [diff] [review] Patch v2 looks good!

Landed as: http://hg.mozilla.org/qa/mozmill-automation/rev/6293eb5da30f

A regression has been regressed by that landing. Now the add-ons testrun is reported as report_type="mozmill-test". Patch upcoming.

Comment on attachment 522775 [details] [diff] [review] follow-up for report_type wfm :)

Followup landed as: http://hg.mozilla.org/qa/mozmill-automation/rev/09a8c8680010