1057015 - Proper deployment + cache-control headers

Status: RESOLVED FIXED

(Data Platform and Tools :: General, defect)

Description

[Jonas Finnemann Jensen (:jonasfj)]

In bug 1017155 we got SSL for telemetry.mozilla.org which is done through cloudfront.
But some of our files really shouldn't have 24 hours delay.

For example /v1/telemetry.js, we need to update that when we move data files.

So we should specify cache-control header when uploading files to S3.
I'm okay with setting cache-control to 1 minute or less :)

We use cloudfront just to get the SSL support, not to get a CDN.

Also we need a smarter way to deploy this dashboard. I suggest that we use travis-ci.
Ie. create a travis.yml file with encrypted AWS credentials for an IAM user that only has access to the telemetry.mozilla.org bucket.

This way, we can also do some preprocessing before uploading, if we should ever want to do that... Perhaps in the future we'll write telemetry.js using browserify.
Oh, and it'll enable to run some simple tests, I believe we already have some for telemtry.js

I think this might work:
http://docs.travis-ci.com/user/deployment/s3/

But it doesn't seem to set cache-control headers, so we probably have to install aws-cli tools and do a custom deployment script:
http://docs.travis-ci.com/user/deployment/custom/


Note, that we currently have something deploying to S3, running as a cron job.. .That should be killed when this is running. It lives on the dashboard aggregation node.
Ask jonasfj, if you forget where that node lives :)

Comment 1

[Chris H-C :chutten]

:whd, is this 3-year-old bug still relevant to how tmo is deployed these days?

Comment 2

[Wesley Dawson [:whd]]

:rvitillo, :mreid and I replaced the cron s3 upload version of this with a github-pages based setup at some point between 3 years ago and now. We also no longer have a 24 hour delay from GH pages pushes to CDN propagation that I am aware of (I believe it is on the order of minutes). Closing this.