1008108 - Show additional information beside the folder name for the long-term inbound archive when accessing it via HTTP protocol

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Right now only the folder name with the unix timestamp is shown. This is kinda hard to handle when you are looking out for a specific build during a regression test. It would be great to also see the additional information like last modified.

http://inbound-archive.pub.build.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linux64/

Comment 1

[Pete Moore [:pmoore][:pete]]

Hi Henrik,

We upload to ftp.mozilla.org, and then sync to S3 (the inbound-archive site).

Therefore, for *more recent* builds only, you should also be able to download from the equivalent ftp folder:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linux64/

This view shows the last modified date.

Since we keep more history in S3, this may not be sufficient, since older binaries are cleaned out more quickly that they are from ftp.

Agreed that the directory displays on inbound-archive should include last modified date - so we should definitely try to fix this.

Pete

Comment 2

[Pete Moore [:pmoore][:pete]]

(of course via http too: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-linux64/)

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

We're not showing mtimes on directories because it is slow to do so, making the load time for the pages more than 30s. This is a result of storing the mtime as metadata on the S3 key, and having to make an API for each dir to query that. In turn that's because S3 stores the time you sync files (Last Modified) rather than the original mtime, and not even that on the way they simulate directories.

Going back a step, why do you need the modification time ? Builds would not be started out of sequence with the hg push log.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Well, as what we have right now makes it very hard for us to run regression tests for older tinderbox builds. So if we even don't have a correct order of builds, what can be done to make our life easier? Maybe using the changeset would be an option, so you can directly find your appropriate build? Not sure what else could help.

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

I don't know anything about the regression tests, but you'd like to have a mapping from revision to url-for-installer ? (branch, platform, build type would be other inputs presumably). In which case that's bug 487036 (aka write an API to kill all the ftp scrapers)

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+2]]

My point was more about the manual regression testing without any other tool. But if we want to force using a tool like mozregression, anything as listed here might not be necessary.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

Can't fix this as requested. Would need more information about the workflow to suggest alternatives.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Maybe its really time to use mozregression all the time.