Closed
Bug 1218333
Opened 9 years ago
Closed 9 years ago
delivery: shorter caching interval for /pub/*/nightly/latest* (nightly.mozilla.org is linking to outdated builds)
Categories
(Cloud Services :: Operations: Miscellaneous, task)
Cloud Services
Operations: Miscellaneous
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gcp, Assigned: oremj)
Details
nightly.mozilla.org links to https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/
but that directory is outdated with the latest build being from 20th of October. The actual latest Nightly is from the 25th of October.
Comment 1•9 years ago
|
||
We used to have a one hour expiry for nightly/latest-* dirs, eg
$ curl -I http://ftp-origin-scl3.mozilla.org/pub/firefox/nightly/latest-trunk/firefox-44.0a1.en-US.win32.installer.exe
HTTP/1.1 200 OK
Server: Apache
X-Backend-Server: ftp5.dmz.scl3.mozilla.com
Cache-Control: max-age=3600
...
Now it looks like several days:
$ curl -I http://archive.mozilla.org/pub/firefox/nightly/latest-trunk/firefox-44.0a1.en-US.win32.installer.exe
HTTP/1.1 200 OK
Content-Type: application/x-msdownload
Content-Length: 44918064
Connection: keep-alive
Date: Mon, 26 Oct 2015 09:57:09 GMT
x-amz-replication-status: COMPLETED
x-amz-version-id: U56w14rJAILAl0QNHF3LbbvFa0CT51F_
Last-Modified: Tue, 20 Oct 2015 00:44:48 GMT <--------- !!
ETag: "d7b0ebf91d73416d60d13644454ca8f6-6"
Accept-Ranges: bytes
Server: AmazonS3
X-Cache: Miss from cloudfront
Via: 1.1 63147df114f2fa4040652c8e4a79d851.cloudfront.net (CloudFront)
X-Amz-Cf-Id: bsUpvkgzQA4IyDQOQGnLLPiGilaOWAXEDl4CeFTNW_mjRfBvhHfFgw==
Please check the Apache/Zeus configs for any other snowflakes.
Assignee: nobody → oremj
Component: Other → Operations
Product: Websites → Cloud Services
Summary: nightly.mozilla.org is linking to outdated builds → delivery: shorter caching interval for /pub/*/nightly/latest* (nightly.mozilla.org is linking to outdated builds)
Assignee | ||
Comment 2•9 years ago
|
||
This is fixed in https://github.com/mozilla-services/product-delivery-tools/pull/40
I just deployed the fixed binary, so this will take effect when the next nightly builds enter the cache. To expedite, we can invalidate the current cache after the nightly builds land on s3.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•