delivery: shorter caching interval for /pub/*/nightly/latest* (nightly.mozilla.org is linking to outdated builds)

RESOLVED FIXED

Status

Cloud Services
Operations
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: gcp, Assigned: oremj)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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.
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

3 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
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.