Here’s how to stop your site’s uploads or other static file directories disappering after doing a ‘cap deploy’ with Capistrano. Capistrano is actually behaving exactly as it should. The problem is that the ‘uploads’ directory is being left behind in release purgatory while the other files happily move on up to the castle in the sky that is the current release.
The solution is to have all uploads stored in a directory outside of the release system. As usual the smart folks who made Capistrano are way ahead of us, if you do a ‘ls’ in your apps path (on your remote machine) you’ll see four directories
$ ls
current releases revisions.log shared
‘cd’ into shared/system (cd shared/system) and create an uploads directory (mkdir uploads). Next create a Capistrano task in config/deploy.rb (on your local machine) that symlinks the public uploads directory in the latest release to the shared/system/uploads directory. The example below would be the task for using Capistrano on Media Temple’s Grid Server …
task :after_update_code, :roles => :app do
run "ln -nfs /home/#{site}/containers/rails/#{application}/shared/system/uploads #{release_path}/public/uploads"
end
That’s it! Your uploads are now release agnostic.
This entry was written by
Alastair, posted on
March 13, 2007 at 11:46 am, filed under
Capistrano,
Media Temple,
Ruby on Rails. Bookmark the
permalink. Follow any comments here with the
RSS feed for this post.
or leave a trackback:
Trackback URL.
© Copyright 2006 - 2012 Alastair Dawson
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
5 Comments
THANKS MAN!
I can’t seem to get this to work… Is there any reason why copying all of my files to the new release directory wouldn’t work (it doesn’t…)? How would I go about making sure the symlink is actually being created there on the server? After deploying, the files are still ending up in the release directory and not the shared/system folder ;(
It’s rather late right now, so advanced apologies if this doesn’t make any sense.
I can’t seem to get this to work either. My problem is similar to Greg’s. Is there anything else that needs to be done? Permissions? Do I need to svn ignore the local uploads directory?
Hey David, you’re right about setting svn ignore on the local uploads directory. I should have mentioned that for every site I set up right after the initial svn check in I set all ‘dynamic’ directories to be ignored. Hopefully that will fix it for you.
hi David,
thanks for the info – between this and the capistrano source I figured out how to make my assets directory persistent.
for anyone stumbling in, the file callbacks.rb in capistrano 2.4.3 suggests that tasks named ‘after_xxx’ and ‘before_xxx’ aren’t recommended – instead, the before and after methods should be used.
so, here’s my task for symlinking an assets directory;
namespace :deploy do
#desc “Symlink assets directory from latest release (*)”
task :finalise_update_assets, :except => { :no_release => true } do
run “ln -s #{shared_path}/assets #{latest_release}/public/assets”
end
end
after “deploy:finalize_update”, “deploy:finalise_update_assets”
2 Trackbacks
[...] Um das zu verhindern (hier gefunden) muss man im meinprojekt/shared Verzeichnis auf dem Server wo man es deployed hat die Verzeichnisse erstellen, die solche wichtigen Sachen enthalten. [...]
[...] Vixiom Axioms » Stop uploaded files getting ‘deleted’ with Capistrano [...]