463034 - provide a better hourly builds archive

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[(mostly gone) XtC4UaLL [:xtc4uall]]

first of all sorry if this is the wrong component and if this is a dupe. please move/close this report if necessary.

after the switch to HG/mozilla-central infrastructure regression finding in trunk development is/could be some kind of pain in the a**.

there's just 24h of builds available, e.g. ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32/

compared to http://hourly-archive.localgho.st/ this is pretty poor.
i'd like to see an archive of hourly builds of the last 4-7 days for all supported platforms available.

moreover the dir listing could be improved by including the checkout time in the dir name instead of a cryptic number.

Comment 1

[[e-mail] (:bhearsum)]

We specifically will not do this because of disk space requirements. Especially with 3.1 we have *lots* of "hourly" builds. Often we have one per platform per check-in.

This is in fact better than where we were less than a year ago. We used to store *no* hourly builds at all - we'd just overwrite the same file every time.

The directory name is very important to our Talos setup - we cannot change that. That name is the unix time of the build start time. It matches up with the build start time on the Tinderbox page. Build checkout time is not a very useful thing for Mercurial builds. 

For Mercurial based builds the changeset + repository is recorded in application.ini.

It's a fine idea in principle, but the disk space requirements are too onerous.

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

ok, *sigh*, thanks for that explanation, Ben.
i guess if it has been possible you'd have done this long before yet.
at least i can say that i tried it :-).

Comment 3

[Steve England [:stevee]]

I find it hard to believe all the added value hourly builds bring is being denied simply over HD space. Picking three build machines (one for each OS) and providing 2 days worth of hourlies for each surely can't take up so much space.

Nightly testers are often very quick to notice regressions so having 2 days worth of hourlies makes it much easier for us to find a range and start pointing fingers.

Also many of us keep our own local hourly archives. Obviously we can't be awake 24/7 to monitor a build machine's output to build our library, so having 2 days worth of history allows us to download a bunch of builds each day to keep for future range finding.

Comment 4

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

For some perspective, hourly-archive.localgho.st is something I set up with Peter6 and Steve's help, it runs on VM and isn't officially supported by Mozilla. That said, I have been trying to find time to make a better version for mozilla-central builds - certainly having the revision stored in application.ini will make life easier. If you care enough to help then get in touch and maybe we can work something out.