1260985 - Update Linux debug jsshell earliest known working builds to 2015-07-31

Status: RESOLVED INVALID

(Testing :: mozregression, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I was testing out mozregression 2.3.3, and found that the first good earliest known working build for Linux debug jsshell should be bumped to 2015-07-31 maybe somewhere near this line[1].

Otherwise, it keeps on spewing out the following output spam format:

 <timestamp> WARNING: Skipping build <hash>: Unable to find build info using the taskcluster route 'buildbot.revisions.<another hash>.mozilla-inbound.linux64-debug'

until approximately the end of July 2015.

Noting that seems to neatly coincide with a 8 month timeframe, I hope this doesn't mean that we need to continue bumping it further in the future.

[1] https://github.com/mozilla/mozregression/blob/5134ed9/mozregression/cli.py#L327

Comment 1

[William Lachance (:wlach)]

Selena, is there some kind of time limit for how long we're storing jsshell builds in taskcluster?

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

fwiw, this seems to only be related to debug builds.

I can seem to still retrieve opt jsshell builds from the earliest known date of 2012-04-18 as we've defined in mozregression.

Comment 3

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Sample CLI command used when trying to bisect the fix for bug 1122993:

~/trees/venv-mozregression/bin/mozregression --persist tmp/ --background-dl-policy keep --bits 64 --app jsshell -B debug --command '{binary} --fuzzing-safe --no-threads --no-ion a.js'

Comment 4

[Selena Deckelmann :selenamarie :selena]

(In reply to William Lachance (:wlach) from comment #1)
> Selena, is there some kind of time limit for how long we're storing jsshell
> builds in taskcluster?

That might be the beginning of history in TaskCluster. :mshal? :jonasfj?

Comment 5

[Jonas Finnemann Jensen (:jonasfj)]

You can see in a task definition when it expires. Too many things have been defaulted to 1 year, so
it's probably 1 year.

But maybe things weren't indexed correctly before?
Try and look up some of the <hash> keys that don't work in the index browser, maybe the task expired.
Or maybe (most likely) it wasn't indexed with the route mentioned. That would be nice guess.

Comment 6

[Michael Shal [:mshal]]

We have data for these pushes, but this was when some of the hashes were truncated to 12 characters, so the actual route it would need to use is:

buildbot.revisions.047a8e82579f.mozilla-inbound.linux64-debug

instead of:

buildbot.revisions.047a8e82579f56ec153147ec90bff6f2fd46286b.mozilla-inbound.linux64-debug

We have a few options here, I think:

1) Clean up the index by backfilling routes with the correct info (we could backfill gecko.v2 and always use that instead of sometimes using gecko.v2 and sometimes buildbot.X)

2) Add another date hack so we can use a 12-character hash for revisions before bug 1175655 landed, and a 40-character hash afterward.

3) Unify debug and opt builds, so they behave similarly at least.

I'm not really sure what would be involved for option 3). :parkouss, do you have any info on why these are different? It looks like should_use_taskcluster() returns 1 in the debug case, but I'm not really sure why that should be different. Also, I thought we had support to use archive.m.o for older inbound revisions, but I can't seem to find that. Is that gone now? If we still have support for that, we could use archive.m.o for older builds and just set the date for using the index to be when we started using 40-character revisions.

Personally, I would vote for #1, but I don't have time currently to do that myself in the immediate future. One of the hackier solutions could probably solve this particular case until we are able to do that.

Comment 7

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

(In reply to Michael Shal [:mshal] from comment #6)
> Also, I thought we had support to use
> archive.m.o for older inbound revisions, but I can't seem to find that. Is
> that gone now? If we still have support for that, we could use archive.m.o
> for older builds and just set the date for using the index to be when we
> started using 40-character revisions.

See also bug 1233909.

Comment 8

[Julien Pagès (:parkouss)]

(In reply to Michael Shal [:mshal] from comment #6)

> I'm not really sure what would be involved for option 3). :parkouss, do you
> have any info on why these are different? It looks like
> should_use_taskcluster() returns 1 in the debug case, but I'm not really
> sure why that should be different. Also, I thought we had support to use
> archive.m.o for older inbound revisions, but I can't seem to find that. Is
> that gone now? If we still have support for that, we could use archive.m.o
> for older builds and just set the date for using the index to be when we
> started using 40-character revisions.

Yes, should_use_taskcluster() returns True for the debug builds - I
don't remember exactly why, but I guess it is just that most of the time we
don't have those builds on a.m.o.

Comment 9

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Will requests a needinfo? :)

Comment 10

[William Lachance (:wlach)]

I'm afraid I don't have time to look into this in more detail. :(

Comment 11

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

There has been no more debug builds since 2015-10-21:

https://ftp.mozilla.org/pub/firefox/nightly/2015/10/2015-10-21-mozilla-central-debug/

seems to be the last available date.

I guess we can resolve this INVALID since it no longer applies!