1096250 - mozregression-script.py: error: no such option: --repo

Status: RESOLVED FIXED

(Testing :: mozregression, defect)

Description

[Ed Morley [:emorley]]

The instructions page (http://mozilla.github.io/mozregression/) says:

Use nightlies from a different repo/branch
$ mozregression --repo=mozilla-1.9.2

However using "--repo" gives:

$ mozregression --repo=mozilla-beta --good=2014-11-01
Usage: mozregression-script.py [options]

mozregression-script.py: error: no such option: --repo

Comment 1

[Vaibhav (:vaibhav1994)]

It looks like --inbound-branch is used instead of --repo: https://github.com/mozilla/mozregression/blob/master/mozregression/regression.py#L372

:wlach, I think we should change the instructions page: http://mozilla.github.io/mozregression/

Comment 2

[William Lachance (:wlach)]

Yup, that sounds right to me. Feel free to modify the gh-pages repository with the change. Note that we're thinking of creating a readthedocs site for mozregression where advanced topics like this will probably end up being covered in more detail, see bug 1107602.

Comment 3

[William Lachance (:wlach)]

Ok, I think this is actually a more serious bug. We're basically using the inbound-branch option for two things at this point: 

(1) choosing the inbound branch to bisect (mozilla-inbound, b2g-inbound, fx-team, ...)
(2) choosing the type of nightly we want to test (mozilla-central, mozilla-aurora, or mozilla-beta)

I think we need to add the --repo option back and use that when we're doing nightly bisection (as opposed to inbound_branch which we're using). We should also modify the internal variable names inside build_data.py accordingly. 

Julien, does this make sense?

Comment 4

[Julien Pagès (:parkouss)]

Yes, that make sense for me. It is confusing currently in the code, and probably not working for the nightly repo.

We probably should start in fetch_configs.NightlyConfigMixin class. There is a method called "nightly_inbound_branch" which takes a date and returns for example 'trunk' or 'mozilla-central' for firefox.

I think this is what we are talking about here for repo (correct me if needed). We should implement a way to override the returned value with the --repo command line arg, and by the way give this method a better name with some documentation. build_data.py will then only need to reflect the renamed method.

Comment 5

[Julien Pagès (:parkouss)]

I started to work on this. Basically I think it is fine (you can hae a look here: https://github.com/parkouss/mozregression/commit/623c4092aba5276ec3fbb9164cd2e7974ab4dce4)

There is still one problem when going when coming to inbound bissection. For example:

mozregression -g 2014-11-20 -b 2014-11-21 --log-mach-level debug --repo mozilla-aurora
 0:00.00 LOG: MainThread Build Finder DEBUG We need to fetch the lower limit
 0:00.00 LOG: MainThread Build Finder DEBUG We need to fetch the higher limit
 0:00.00 LOG: MainThread Build Finder DEBUG We got 2 folders, we need to fetch [0, 1]
 0:04.70 LOG: MainThread Build Finder DEBUG Now we got 2 folders - 0 were bad
 0:04.70 LOG: MainThread Bisector INFO Got as far as we can go bisecting nightlies...
 0:04.70 LOG: MainThread Bisector INFO Ensuring we have enough metadata to get a pushlog...
 0:05.52 LOG: MainThread Bisector INFO Last good revision: 3056a819bc0f (2014-11-20)
 0:05.53 LOG: MainThread Bisector INFO First bad revision: 210f8669a990 (2014-11-21)
 0:05.53 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=3056a819bc0f&tochange=210f8669a990

 0:05.53 LOG: MainThread Bisector INFO ... attempting to bisect inbound builds (starting from previous week, to make sure no inbound revision is missed)
 0:07.18 LOG: MainThread Bisector INFO Getting inbound builds between 7d31662bcc98 and 210f8669a990
Traceback (most recent call last):
  File "/home/jp/dev/mozregression/venv/bin/mozregression", line 9, in <module>
    load_entry_point('mozregression==0.30', 'console_scripts', 'mozregression')()
  File "/home/jp/dev/mozregression/mozregression/regression.py", line 502, in cli
    app()
  File "/home/jp/dev/mozregression/mozregression/regression.py", line 258, in bisect_nightlies
    self.bisect_inbound()
  File "/home/jp/dev/mozregression/mozregression/regression.py", line 149, in bisect_inbound
    range=60*60*12)
  File "/home/jp/dev/mozregression/mozregression/inboundfinder.py", line 65, in get_build_infos
    pushlogs = pushlogs_finder.get_pushlogs()
  File "/home/jp/dev/mozregression/mozregression/inboundfinder.py", line 36, in get_pushlogs
    response.raise_for_status()
  File "/home/jp/dev/mozregression/venv/lib/python2.7/site-packages/requests/models.py", line 795, in raise_for_status
    raise HTTPError(http_error_msg, response=self)
requests.exceptions.HTTPError: 404 Client Error: Not Found

This is because we are trying to fetch changesets with the following url:

https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?fromchange=7d31662bcc98&tochange=210f8669a990

And if you follow this link, you will see "unknown revision '7d31662bcc98'". 

Is https://hg.mozilla.org/releases/mozilla-aurora/json-pushes?fromchange=3056a819bc0f&tochange=210f8669a990 the good candidate ? I took this from the printed pushlog url.

Comment 6

[William Lachance (:wlach)]

We should probably only fall back to bisecting inbound when bisecting mozilla-central. Any other branch doesn't really make any sense.

Comment 8

[Julien Pagès (:parkouss)]

Attachment: Add a repo command line option

Comment 9

[William Lachance (:wlach)]

Comment on attachment 8534925 [details] [review]
Add a repo command line option

Looks pretty reasonable, merged!

Comment 10

[Julien Pagès (:parkouss)]

Let's close this bug as it is fixed.