Rails 4 Asset Caching Doesn't Clean Old Assets #123
Comments
|
If needed, I can keep that app frozen on Heroku so it can be looked at by staff. |
|
@MatthewMcMillion I think we have a fix in mind. Can you fork it and provide the app name of the fork? |
|
Yep, you can use 'bitpivot-web'. |
|
I can confirm that Rails4 does clean assets on heroku. However it takes 3 changes to that file for sprockets to clear out the files. Steps, run this 4 times and compare output: Closing this issue. |
|
The problem isn't with changed files, it's with deleted files. The files were removed 20 or 30 commits ago, but still end up in asset precompile output. |
|
Ill check that case. Thanks for the info. |
|
I can confirm that This isn't an issue with Heroku but rather sprockets and sprockets-rails which provides those rake tasks. Seems bad that deleted assets never get removed and will continue to grow indefinitely. A read through cache would eventually fix this issue on our end. If you want to push a file out of cache for security reasons, I would recommend creating a new blank file with the same name, then modify it by adding whitespace and push three times. It's not ideal but it's better than nothing. |
|
I can also confirm that |
Right now sprockets will preserve the last number copies of an asset after it is modified, lets call this `keep`. If clean is called `X` more times than `keep` is specified and there are more than `keep` copies, then `X` backups will be removed from the file system. This behavior has two desirable behaviors: allowing for rolling deploys since we may need to render old assets from the new server on deploy, and preventing the compiled asset directory from growing continuously. Right now if a user deletes an asset, it will not be removed from the compiled directory regardless of how many times compile or clean are called. If a developer needs to delete files frequently, this means that the compiled directory will only continue to grow in size even if clean is being called. A user may need to delete an asset due to security concerns: heroku/heroku-buildpack-ruby#123 and it is currently impossible without resorting to a hack. This PR allows sprockets to remove files from the compiled directory that have been deleted from the source directory. To do this we need to tag each asset with a `compiled_at` time and store a global `compiled_at` time to know the last time compile was run. Instead of being deleted instantaneously, removed assets are stored in a `deleted_assets` key in the top level manifest. Every time `clean` is run it will increment a `generation` in the asset. When `generation` == `keep` then the asset will be removed from the project. This allows us to preserve rolling deploy functionality for deleted assets, while not allowing the deleted assets to continue to take up an ever increasing amount of space. ATP
Right now sprockets will preserve the last number copies of an asset after it is modified, lets call this `keep`. If clean is called `X` more times than `keep` is specified and there are more than `keep` copies, then `X` backups will be removed from the file system. This behavior has two desirable behaviors: allowing for rolling deploys since we may need to render old assets from the new server on deploy, and preventing the compiled asset directory from growing continuously. Right now if a user deletes an asset, it will not be removed from the compiled directory regardless of how many times compile or clean are called. If a developer needs to delete files frequently, this means that the compiled directory will only continue to grow in size even if clean is being called. A user may need to delete an asset due to security concerns: heroku/heroku-buildpack-ruby#123 and it is currently impossible without resorting to a hack. This PR allows sprockets to remove files from the compiled directory that have been deleted from the source directory. To do this we need to tag each asset with a `compiled_at` time and store a global `compiled_at` time to know the last time compile was run. Instead of being deleted instantaneously, removed assets are stored in a `deleted_assets` key in the top level manifest. Every time `clean` is run it will increment a `generation` in the asset. When `generation` == `keep` then the asset will be removed from the project. This allows us to preserve rolling deploy functionality for deleted assets, while not allowing the deleted assets to continue to take up an ever increasing amount of space. ATP
Right now sprockets will preserve the last number copies of an asset after it is modified, lets call this `keep`. If clean is called `X` more times than `keep` is specified and there are more than `keep` copies, then `X` backups will be removed from the file system. This behavior has two desirable behaviors: allowing for rolling deploys since we may need to render old assets from the new server on deploy, and preventing the compiled asset directory from growing continuously. Right now if a user deletes an asset, it will not be removed from the compiled directory regardless of how many times compile or clean are called. If a developer needs to delete files frequently, this means that the compiled directory will only continue to grow in size even if clean is being called. A user may need to delete an asset due to security concerns: heroku/heroku-buildpack-ruby#123 and it is currently impossible without resorting to a hack. This PR allows sprockets to remove files from the compiled directory that have been deleted from the source directory. To do this we need to tag each asset with a `compiled_at` time and store a global `compiled_at` time to know the last time compile was run. Instead of being deleted instantaneously, removed assets are stored in a `deleted_assets` key in the top level manifest. Every time `clean` is run it will increment a `generation` in the asset. When `generation` == `keep` then the asset will be removed from the project. This allows us to preserve rolling deploy functionality for deleted assets, while not allowing the deleted assets to continue to take up an ever increasing amount of space. ATP
|
I'm having an issue that looks like this. At least in my case, what's going on is that the assets Rake tasks think that the assets directory is |
|
@hone Sup! Any status on this issue? Is there a good workaround at the moment to delete the old assets? My app is http://enroll-staging.herokuapp.com and I'm pretty sure the wonky assets behavior I'm getting are related to this issue. Any way to definitely test to tell if this is affecting my app? |
|
hey @jessmartin! We need to catch up sometime. I don't have any news here yet. This issue is basically there are assets that you delete that are still available b/c |
|
Terence - found the problem and it wasn't related. And we should definitely catch up sometime! On Fri, Sep 6, 2013 at 4:06 PM, Terence Lee
Jess Martin Jess Martin |
|
@jessmartin what was the issue? I'm encountering something similar but it looks like the manifest ends up being wrong so my pages reference the wrong compiled file. |
|
@r38y I'm wracking my brain, but honestly I can't remember. I even went back and looked at my commits from that day - nothing. I'm pretty sure I had something configured incorrectly on my end. It didn't turn out to be a heroku problem. |
|
@jessmartin thanks for trying. After hours of banging my head against the wall, I figured out it was a single file "manifest.json" that was generated a while back when we tried the first (non-complete) rake task at the top of https://gist.github.com/eric1234/5692456. |
|
I am also being affected by this, an old javascript file that should no longer exist is still hanging around and is causing bugs. |
|
Try /~https://github.com/schneems/sprockets_better_errors It's likely a missing asset dependency declaration. On Wed, Jan 22, 2014 at 8:45 AM, Dominic Barker notifications@github.com
|
|
I was also affected by this issue. I was able to resolve it (i.e. uncache all my assets on Heroku) by incrementing the config.assets.version variable in ${project-root}/config/application.rb This causes all the URL hashes to be modified, and means that no old files are included in the application. |
|
@andybry would you mind elaborating on this a bit more, perhaps provide an example of what you done? I'm having same issue with old assets being uploaded, would appreciate anything you can contribute, thank you |
|
@richlewis14 I can't show you the actual example because its in proprietary code owned by the company I work for, but here's an example of what I meant in a bare bones Rails 4 application: andybry/assets-increment-example@5fad722 and then push to Heroku. Any dramatic changes to the assets should further increment the number in that string to prevent similar issues. I've seen some posts on the Web that claim that you only need to use that configuration variable when upgrading from Rails 3 to 4, but nonetheless it did work for me (I think sprockets uses it when it's generating the hashes it uses in caching compiled files and in URLs, so it just causes everything to uncache). Perhaps Heroku is another use case that its suited to. Hope that's helpful. |
|
oh i see, you are just manually changing the version number..I thought you had a script that auto increments on each deployment... thanks for the example though |
|
well thats a shame, it did not work for me, still uploaded a lot of images that have been deleted |
|
I'm also suffering from an outdated version of an asset included in compiled output. |
|
I'm having the same problem in a different way. We're using haml_coffee_assets and changed some config settings in |
|
@agrberg that's a different issue. Likely sstephenson/sprockets#534 you need to use |
|
I was also able to fix it using the heroku-repo plugin: /~https://github.com/heroku/heroku-repo. |
|
I ran into this problem, but the solution offered here solved it: http://stackoverflow.com/questions/20241178/rails-4-assets-not-loading-in-heroku-after-rake-assetsprecompile |
|
It's possible that Heroku made some changes/fixes on their end. I'd been having trouble with asset compilation for months, and then yesterday i mistakenly deployed without my precompiled assets and.. everything just worked like it was supposed to again. |
|
Any chance someone found a solution for this problem? This is what As you can see I have a copy of my assets that are 2 months old and it has now become a very big problem because this is making my app hit the 300MB slug size limit. I can't deploy anymore. @schneems or @hone Is there any way I can just manually erase public/assets during a deploy? |
|
You're probably seeing this issue: rails/sprockets-rails#138 Upgrade to the master of To clear your cache, you can use the heroku repo plugin /~https://github.com/heroku/heroku-repo |
|
Hi, @dabit. We solved the problem the following way:
|
|
What i did :
And it worked |
And you'll have to do that EVERY time you deploy unless you fix the underlying problem... Update your sprockets-rails dependency please |
|
We noticed that despite setting our |
The IssueTo clarify this is a known issue (rails/sprockets-rails#138), you can solve it by doing this: The FixUpgrade to the latest sprockets-rails to fix the root issue. To clear your cache manually, you can use the heroku repo plugin /~https://github.com/heroku/heroku-repo. If your "fix" involves rev-ing the version constantly or constantly using the repo plugin, it's not really a fix. If you have a different issue, or this does not solve your problem please create a new issue. Adding onto this one obscures the fix. |
|
has anyone else managed to upgrade to sprockets-rails master per @schneems comment? we're on rails 4.1.6 and it didn't seem possible since rails 4.16 depends on sprockets-rails ~> 2.0. are there specific changes we could cherry-pick out? |
|
Confirm that using /~https://github.com/heroku/heroku-repo to purge assets works as a fix for this. |
|
It was master at the time of that comment. I believe that commit it is released now. — On Mon, Dec 1, 2014 at 10:11 PM, Andrew Cockerham
|
|
sprocket-rails has the mentioned fix in 2.1.4. Changelog: Pull request: |
|
Thanks for the fix. I had a similar issue that was making me tear my hair out, the heroku-repo tool fixed it :) |
|
I was experiencing similar issue where heroku was serving the old js file 10 commits ago. After precompiling the assets locally then push to heroku finally fixed it. |
To see if it removes old assets from public/assets. I noticed it's still adding old files that were removed a long time ago. Based on this: heroku/heroku-buildpack-ruby#123 I installed the heroku-repo plugin and purged the cache: heroku repo:purge_cache -a ohana-staging
To see if it removes old assets from public/assets. I noticed it's still adding old files that were removed a long time ago. Based on this: heroku/heroku-buildpack-ruby#123 I installed the heroku-repo plugin and purged the cache: heroku repo:purge_cache -a ohana-staging
and others
Since we started caching assets in Rails 4. There's an issue that old assets aren't getting cleared. We need some way of cleaning up old assets that aren't being used anymore.
Update: To clarify, the issue is that there are old assets that are deleted that still linger.
The text was updated successfully, but these errors were encountered: