Make it easier to re-use mozregression in other software

RESOLVED FIXED

Status

Testing
mozregression
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: wlach, Assigned: parkouss)

Tracking

Trunk
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
Created attachment 8446092 [details] [review]
pull request

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 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+
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

4 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

4 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)
[ 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

4 years ago
Sure, I will look at this soon. thanks for the feedback ;)
Flags: needinfo?(j.parkouss)
(Assignee)

Comment 8

4 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.
Cool! This worked well so I merged it.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Updated

4 years ago
Assignee: nobody → j.parkouss
You need to log in before you can comment on or make changes to this bug.