This doesn't make sense to me. AWS S3 bucket names are supposed to be globally unique. These suggestions there don't make sense then because you'd never get away with calling an S3 bucket "dev".

As a matter of fact, I see no reason to have a default here. (I believe the default is DEFAULT_BUCKET_NAME = config("DEPLOYER_BUCKET_NAME", default="dev"))

The dev, stage, and prod options are bucket nicknames or shortcuts for mdn-content-dev, mdn-content-stage, and mdn-content-prod (they're converted to the real bucket name in upload.py). Just a convenience since they're the names we'll be using 99% of the time. I'll change the code to indicate that these are special nicknames.

We discussed this and agreed that it's a bit too magical to use nick names. Instead, let's keep it dumb and spell out the whole bucket name in full.

Instead of comments, and because I wanted to back up what I was about to say, I put this together: https://github.com/escattone/yari/pull/43

Thanks for the cool validation tips! I incorporated all of your suggestions except for:

for fp in content_root.glob("**/_redirects.txt"):

I had originally used that, but it was significantly slower than

            for fp in iterdir(content_root, max_depth=1):
                if fp.name != "_redirects.txt":
                    continue

Since the redirect files are always under the locale, I could use (note the one star):

for fp in content_root.glob("*/_redirects.txt"):

Slower, but can you even notice the difference?

Oh. I didn't know for fp in content_root.glob("*/_redirects.txt"): was a thing even. But that actually makes sense.
But this is all nits in a sense since your existing ad-hoc solution works perfectly fine.

It does make me a bit nervous. Is the ETag creation a public thing in S3?
If our implementation ever diverges from what S3's public API exposes, we'll potentially be uploading what hasn't actually changed.

I hear you, but in practice they probably will never (or at least very rarely) change it, and it seems better to take the risk and not waste the time calculating/storing/fetching our own for each file.

If nobody has pushed almost any changes to Yari's source code in a 24h span, 99% of the Is-it-in-S3-already-or-shall-I-bother-to-upload it will be 99% times benefitting from comparing the ETag since the filename and filesize (both from list_objects_v2) will be identical. AND in the cases in the cases where the only thing changed in the 24h span is a line of SCSS or .tsx or a JS package, then again this code will be a godsend since we'll get the same filename and same filesize but a different ETag value.
So, having it, despite its "risks" is a good idea.