Run build_all whenever assets changed

[ari]

The problem:

• it is easy to forget to run the build_all rake task
• this creates hours of chasing one's tail trying to find the bug in deployment for things that worked fine in development.

A solution:

• Store the most recent datetime of any asset and use that to detect whether anything has been updated since the rake task last ran. Automatically rebuild the assets in this is detected.
• Two ideas for storing the most recent datetime:
• As an extension to the file name (eg. base_packaged_200904051314.css)
• As the actual datetime stamp (last modified) of the of the base_packaged.css file

[bouchard]

This is already handled by the fact that asset_packager checks to see if the packaged files exist, and then rebuilts if they're absent.

Can you elaborate on why you're deploying your packaged assets as part of your deployment?

[ari]

What causes the previously built files to be deleted when you deploy again?

[bouchard]

Ah, there be your problem then. Your deployment strategy, whatever it is, shouldn't be copying files over your old deployment... at the very least you should be using "rsync --delete-after" or a proper deployment framework such as Capistrano.

In that case, asset_packager would work as intended.

In you're just copying files over your old deployment, you'll end up with inconsistencies if any of your files are ever renamed or deleted.

[ari]

Many people (including me) use git for deployment. A deployment branch and then deployment by "git pull". Since the original email a year ago, I've added a rake task to always delete all combined assets.

All other (not Rails) frameworks I've used had timestamp checking on application restart so these issues were automatically solved. Hence my feature request here: a simple (?) built-in safeguard to ensure we aren't serving stale assets.

[bouchard]

Hey ari,

Git deployment is fine, I wasn't trying to disparage your choice of deployment methodologies, but the original point still stands - the reason asset_packager doesn't (shouldn't?) be handling this is that your deployed code should be consistent with your deployed revision. A.k.a. there shouldn't be files left around that weren't specifically deployed. So for example, when deploying with git, that should always be followed with a "git reset --hard HEAD".

Does that make sense?

As for Rails checking timestamps, not sure what you mean? What would it check the timestamps against, specifically? Rails does use timestamps, but that's used for cache-busting goodness on the client-side. As for checking other timestamps, as I wrote above, your deployed code should be only your deployed code, so I can't see that being a problem.

[ari]

I would not want to do a hard reset since sometimes there are files which need to be modified within the deployment environment. git pull does everything which I'd want, except for dealing with cached assets.

By timestamps I mean what I set out in the first feature request at the top of this thread. Packaged assets should never have an older datestamp than any of the assets which are being combined. That introduces extra disk read accesses, but I assume your plugin is already checking for whether the packaged asset exists on every page request.