Closed
Bug 1030314
Opened 10 years ago
Closed 10 years ago
Make it easier to re-use mozregression in other software
Categories
(Testing :: mozregression, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: wlach, Assigned: parkouss)
Details
Attachments
(1 file)
Right now mozregression has a bunch of code for finding builds within a time range which it would be good to use in other projects (e.g. b2ghaystack). This bug is about refactoring mozregression so that it can provide an easy-to-use API to do that.
Reporter | ||
Comment 1•10 years ago
|
||
Here's a link to Julien's pull request which does some of that. Dave, could you review since you're more familiar with the issues around code reuse in mozregression than I?
Attachment #8446092 -
Flags: review?(dave.hunt)
Comment 2•10 years ago
|
||
Comment on attachment 8446092 [details] [review] pull request I think this looks okay, however I think having an additional review from Will would be a good idea. I'm not particularly familiar with mozregression or the various uses of it.
Attachment #8446092 -
Flags: review?(wlachance)
Attachment #8446092 -
Flags: review?(dave.hunt)
Attachment #8446092 -
Flags: review+
Reporter | ||
Comment 3•10 years ago
|
||
Comment on attachment 8446092 [details] [review] pull request In general this looks good. The only thing I would change is that I think the inbound finding cli should stay in. Could you amend that commit and submit a new pull request? After that I'd be happy to merge it in.
Attachment #8446092 -
Flags: review?(wlachance) → review+
Flags: needinfo?(j.parkouss)
Assignee | ||
Comment 4•10 years ago
|
||
Sure - I thought it was useless as it is not exposed as a command line. I'll send a new attachement when is done.
Flags: needinfo?(j.parkouss)
Assignee | ||
Comment 5•10 years ago
|
||
Well it is the same attachement, so I'm not sure if I have to send a new one. I will use a needinfo flag instead. If you can have a look at the pull request again, the changing part starts here [1] (except for the optparse import) and only impact inboundrunner.py I noticed that thunderbird is not handled in inbound runners (that's not due to this patch, it is the case on the current master [2]). Is it a bug, or an intended behavior ? [1] https://github.com/mozilla/mozregression/pull/106/files#diff-d6c5e277645e40eb0b90b69a240e5168L111 [2] https://github.com/mozilla/mozregression/blob/master/mozregression/runinbound.py#L80
Flags: needinfo?(wlachance)
Reporter | ||
Comment 6•10 years ago
|
||
[ sorry about the delay in reviewing, was out for a few days when moving ] Anyway, the patch looks good now. Unfortunately it doesn't work with this test case: (mozregression)wlach@popsicle:~/src/mozregression$ mozregression --inbound --good-rev f78e532e8a10 --bad-rev 776f6d341b3f Getting inbound builds between f78e532e8a10 and 776f6d341b3f Retrieving valid builds from u'http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linux64/1403088274' generated an exception: 404 Client Error: Not Found This works fine with the commits reverted. I suspect it's something simple that's changed, could you investigate?
Flags: needinfo?(wlachance) → needinfo?(j.parkouss)
Assignee | ||
Comment 7•10 years ago
|
||
Sure, I will look at this soon. thanks for the feedback ;)
Flags: needinfo?(j.parkouss)
Assignee | ||
Comment 8•10 years ago
|
||
I found my mistake (a missing final /): https://github.com/parkouss/mozregression/commit/295522069d0cfdaec02156386ca73a40cdc2ae36#diff-d6c5e277645e40eb0b90b69a240e5168R77 The command `mozregression --inbound --good-rev f78e532e8a10 --bad-rev 776f6d341b3f` now seems to works as expected and find 104 revisions (same amount without the patch). It is rebased, the url https://github.com/mozilla/mozregression/pull/106 is still valid.
Reporter | ||
Comment 9•10 years ago
|
||
Cool! This worked well so I merged it.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → j.parkouss
You need to log in
before you can comment on or make changes to this bug.
Description
•