One bucket to rule them all?

[peterbe]

In its current form stumptown-deployer upload /path/to/build will figure out what the S3 bucket name should be based on the current git branch name and some other stuff (e.g. the username). This means, that you get something like this:

I.e. one S3 bucket for every single possible branch name.

How about that there's just one "master bucket" for all of stumptown-deployer instead. And instead, within that bucket you start having the first level of folders that reflect names such as git branch names. E.g.

• bucket: peterbes-stumptown-deployer
  • folders:
    • master
    • experiment-with-bcd
    • fix-broken-image-loader
    • etc

Less pollution of S3 buckets and no need to write a thing that scans for now-empty S3 buckets when all files within it have been deleted.

Big question; Can CloudFront point to a prefix folder in an S3 bucket (configured as a website)??

[peterbe]

@escattone What do you think?

[peterbe]

"Origin Path" seems like the right thing!

[peterbe]

Also, perhaps @limed has some insights here.

[peterbe]

Suppose that we put ALL stumptown static site deployments all in the same folder but with individual root folder names (that'd be depend on the git branch for example), then you'd have just 1 S3 bucket and every single deployed site would need to share any bucket configuration.

For stuff like expirations, I don't think that's a problem because expiration is on a per-key basis.

We're still going to need a script that cleans up. Instead of deleting S3 buckets that are no empty (because all keys within have expired), we're going to need to write a script that disables and deletes all CloudFront distributions whose S3 websites are expired. That's a task we'd need to do anyway.

Are there security implications to consider? One day, there'll (possibly, if Stumptown succeeds) be a static site deployment for the production site of https://developer.mozilla.org. Do we want to run that differently from how we run deployments of PR branches?