Open Bug 1233909 Opened 4 years ago Updated 4 years ago

mozregression should go back further than one year for some 64-bit debug js shells

Categories

(Testing :: mozregression, defect)

defect
Not set

Tracking

(Not tracked)

People

(Reporter: gkw, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Linux 64-bit debug js shells on archive.mozilla.org go back to:

https://ftp.mozilla.org/pub/firefox/nightly/2012/04/2012-04-18-mozilla-central-debug/

so I'm not sure why mozregression mentions that "TaskCluster only keeps builds for one year", then jumps to using 2014-12-19, and carries on not finding any builds.


===
See this log:

$ mozregression --app jsshell --command '~/lithium/interestingness/crashes.py --timeout=2 {binary} --fuzzing-safe --no-threads --ion-eager ~/tobereduced154642.js' --persist tempBuilds -B debug
**********
You should use a config file. Please use the --write-config command line flag to help you create one.
**********

 0:00.03 LOG: MainThread INFO No 'bad' option specified, using 2015-12-19
 0:00.03 LOG: MainThread INFO No 'good' option specified, using 2012-04-18
 0:00.03 LOG: MainThread main INFO Getting mozilla-inbound builds between 2012-04-18 and 2015-12-19
 0:00.03 LOG: MainThread mozregression.fetch_build_info INFO Tasckluster only keep builds for one year. Using 2014-12-19 01:02:42.249292 instead of 2012-04-18.
 0:05.89 LOG: MainThread JsonPushes INFO Using 5e4392cb16c65bcd2561b89616aa9f1c585c65c6 (pushed on 2014-12-19 00:02:20) for date 2014-12-19 01:02:42.249292
 0:05.89 LOG: MainThread JsonPushes INFO Using 6ccee3e477e309ccf092d7ae2489a7ebe636dc19 (pushed on 2015-12-19 00:28:58) for date 2015-12-19
 0:06.29 LOG: Thread-1 Bisector WARNING Skipping build 5e4392cb16c65bcd2561b89616aa9f1c585c65c6: Unable to find build info using the taskcluster route 'buildbot.revisions.5e4392cb16c65bcd2561b89616aa9f1c585c65c6.mozilla-inbound.linux64-debug'
 0:06.40 LOG: Thread-2 Bisector WARNING Skipping build 1fd17d4e677ac02fc3544f75c179ce82f451c5fa: Unable to find build info using the taskcluster route 'buildbot.revisions.1fd17d4e677ac02fc3544f75c179ce82f451c5fa.mozilla-inbound.linux64-debug'
 0:06.43 LOG: Thread-3 Bisector WARNING Skipping build 6ccee3e477e309ccf092d7ae2489a7ebe636dc19: Unable to find build info using the taskcluster route 'buildbot.revisions.6ccee3e477e309ccf092d7ae2489a7ebe636dc19.mozilla-inbound.linux64-debug'
/snip
TascCluster is used because you specified the -B option.
TaskCluster only keeps builds one year, but not sure everything worked one year ago or worked in a same way.

See one of the builds:

https://tools.taskcluster.net/index/#buildbot.revisions.1b5e08c0757293e7a6dd4fb519d116cfa6c1019c.mozilla-inbound/buildbot.revisions.1b5e08c0757293e7a6dd4fb519d116cfa6c1019c.mozilla-inbound

So, no debug build, and anyway the names looks weird to me. We are going to switch to use the gecko.v2 TC route soon (I guess January will be fine). This route should be more stable, and builds would be available from I think August 1, 2014 (then again one year cycle).
> TascCluster is used because you specified the -B option.

Should this mode also find builds in archive.mozilla.org?

e.g. https://archive.mozilla.org/pub/firefox/nightly/2012/04/2012-04-18-mozilla-central-debug/
(In reply to Gary Kwong [:gkw] [:nth10sd] from comment #2)
> Should this mode also find builds in archive.mozilla.org?
> 
> e.g.
> https://archive.mozilla.org/pub/firefox/nightly/2012/04/2012-04-18-mozilla-
> central-debug/

Oh, if we can find debug builds by using the pattern {year}/{month}/{year}-{month}-{day}-{branchname}-debug then definitely we should do that!

Let's follow that in bug 1234029.
Depends on: 1234029
Depends on: 1234030
Blocks: 1236101
You need to log in before you can comment on or make changes to this bug.