Open Bug 1260985 Opened 3 years ago Updated 3 years ago

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

Categories

(Testing :: mozregression, defect)

All
Linux
defect
Not set

Tracking

(firefox48 affected)

Tracking Status
firefox48 --- affected

People

(Reporter: gkw, Unassigned)

Details

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
Selena, is there some kind of time limit for how long we're storing jsshell builds in taskcluster?
Flags: needinfo?(sdeckelmann)
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.
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'
(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?
Flags: needinfo?(sdeckelmann)
Flags: needinfo?(mshal)
Flags: needinfo?(jopsen)
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.
Flags: needinfo?(jopsen)
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.
Flags: needinfo?(mshal) → needinfo?(j.parkouss)
(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.
(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.
Flags: needinfo?(j.parkouss)
Will requests a needinfo? :)
Flags: needinfo?(wlachance)
I'm afraid I don't have time to look into this in more detail. :(
Flags: needinfo?(wlachance)
You need to log in before you can comment on or make changes to this bug.