Hacker News new | ask | show | jobs
by arthur_debert 5419 days ago
On universalsubtitles.org, we're doing something pretty similar to that.

1) Move all static media to a unique hash (we get that from git's commit id, making it trivial to correlate code & static) to /[static-media]/[static-cache]/[git commit uid]/...path to file

2) Set the MEDIA url accordingly

The nice thing about this is that the generated file names are very readable and you always know what changeset generated it just by looking. It's open source if someone finds it useful https://github.com/8planes/mirosubs/tree/master/apps/unisubs...

1 comments

That's a pretty good approach. I guess the main drawback is that the git commit hash will change far more often than the contents of most of the static files, though, right?
Of course, but when in development, we use the a template tag that inserts the original url (no commit hash mangling on MEDIA URL), which means that yes, for each deployment we nuke statics, but on our dev cycle that would happen any way (it's very rare to have a release that does not touch static files), so it's not an issue in practice
We've written our CSS and JavaScript to have a bunch of reusable components, so often we can deploy new features without changing our static assets at all (we reuse classes for components that are already in use elsewhere on the site). I can see how for heavier JS sites this wouldn't be worthwhile though.
That's exactly why we don't use git commit hashes - we only want our users to download new versions when the files have definitely changed.