Closed
Bug 745553
Opened 13 years ago
Closed 13 years ago
Updates for some Nightly/ESR10 builds are missing
Categories
(Release Engineering :: General, defect, P2)
Release Engineering
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: whimboo, Assigned: nthomas)
Details
(Whiteboard: [ftp][cachingishard])
Attachments
(1 file)
1.41 KB,
patch
|
Pike
:
review+
khuey
:
review+
nthomas
:
checked-in+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•13 years ago
|
||
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
Assignee | ||
Comment 2•13 years ago
|
||
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.
Assignee | ||
Comment 3•13 years ago
|
||
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>.
Assignee | ||
Comment 4•13 years ago
|
||
(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.
Updated•13 years ago
|
Component: Release Engineering: Automation (Release Automation) → Release Engineering: Automation (General)
QA Contact: bhearsum → catlee
Reporter | ||
Comment 5•13 years ago
|
||
(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
Reporter | ||
Comment 6•13 years ago
|
||
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
Assignee | ||
Comment 7•13 years ago
|
||
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.
Updated•13 years ago
|
Priority: -- → P2
Whiteboard: [ftp][cachingishard]
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → nrthomas
Assignee | ||
Comment 8•13 years ago
|
||
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.
Attachment #627100 -
Flags: review?(l10n)
Comment 9•13 years ago
|
||
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?(l10n)
Attachment #627100 -
Flags: review?(khuey)
Attachment #627100 -
Flags: review+
Attachment #627100 -
Flags: review?(khuey) → review+
Assignee | ||
Comment 10•13 years ago
|
||
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+
Comment 11•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Product: mozilla.org → Release Engineering
Updated•7 years ago
|
Component: General Automation → General
You need to log in
before you can comment on or make changes to this bug.
Description
•