Seen by our Mozmill CI tests lately. There are some platforms which do not offer updates to the latest version of localized builds. Clicking on the AUS link in the reports show an empty document. Here one example: ja on Win Vista: http://mozmill-ci.blargon7.com/#/update/report/4a49d39bc99bcebf1f54d433671df007 All broken updates can be found in the overview: http://mozmill-ci.blargon7.com/#/update/reports?branch=14.0&platform=All&from=2012-04-12&to=2012-04-15
Hm, the same applies to the OS X 10.0esr10 nightly for en-US: http://mozmill-ci.blargon7.com/#/update/report/4a49d39bc99bcebf1f54d433671c1cf9
Summary: Updates for some localized Nightly builds are missing → Updates for some Nightly/ESR10 builds are missing
Speaking to comment #0: * according to the overview, mozmill checked en-US, de, and ja; both locales weren't served an update * in fact that's a problem for all localised builds for Windows on m-c (from inspection of the update snippets) * it turns out that both of the properties previous_buildid and buildid have value 20120414030731, which means we didn't receive the en-US build from the 15th when downloading it from ftp.m.o * we pulled down these files http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-14.0a1.en-US.win32.zip http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-14.0a1.en-US.win32.installer.exe I bet this is more problems with caching. The filename doesn't change from day to day, and ftp.m.o caches files for one hour after a request. It doesn't check if the file has changed if it gets another request in that hour. So if anyone happens to download the en-US zip/exe in the hour before the new build finishes then ftp.m.o will serve the older build. This isn't windows specific, but is more likely to happen for windows since that's where the users are.
Oh, and we still uploadeded snippets to AUS but that intentionally requires that the buildID must increase for it to make an offer. When it's the same it just returns the empty <updates></updates>.
(In reply to Henrik Skupin (:whimboo) from comment #1) > Hm, the same applies to the OS X 10.0esr10 nightly for en-US: > http://mozmill-ci.blargon7.com/#/update/report/ > 4a49d39bc99bcebf1f54d433671c1cf9 This was some missing symlinks for Mac, and would have been broken since nightly updates on esr10 were setup up. Fixed.
Component: Release Engineering: Automation (Release Automation) → Release Engineering: Automation (General)
QA Contact: bhearsum → catlee
(In reply to Nick Thomas [:nthomas] from comment #4) > This was some missing symlinks for Mac, and would have been broken since > nightly updates on esr10 were setup up. Fixed. Thanks. That part works now for ESR builds on OS X: http://mozmill-ci.blargon7.com/#/update/report/4a49d39bc99bcebf1f54d433672d18e9
Has something been fixed here for the Windows builds yesterday? I cannot see any failure for today's updates: http://mozmill-ci.blargon7.com/#/update/reports?branch=14.0&platform=All&from=2012-04-14&to=2012-04-17
As I said in comment #2, given the caching on ftp.m.o we are the whim of whatever requests come in just prior to doing nightly repacks.
Axel, this will mean we always pull the very latest en-US files from a latest-<branch> directory on ftp.m.o, bypassing any caching going on there. I'm hoping this will be a temporary work around while we work on something better with IT, but no-one hold me to that.
Comment on attachment 627100 [details] [diff] [review] Use wget --no-cache Review of attachment 627100 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me, passing an additional request to Kyle.
Attachment #627100 - Flags: review?(khuey) → review+
Comment on attachment 627100 [details] [diff] [review] Use wget --no-cache http://hg.mozilla.org/integration/mozilla-inbound/rev/eb6953f1b20b
Attachment #627100 - Flags: checked-in+
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.