Repository is archived
No commit activity in last 3 years
No release in over 3 years
A deployment strategy for Capistrano 2.0 which combines rsync with a remote cache, allowing fast deployments from SCM servers behind firewalls. Forked from capistrano_rsync_with_remote_cache and fixed couple of errors
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
 Dependencies

Runtime

>= 2.1.0
 Project Readme

Öz Capistrano oz_rsync_with_remote_cache Deployment Strategy¶ ↑

Description¶ ↑

This gem provides a deployment strategy for Capistrano which combines the rsync command with a remote cache, allowing fast deployments from SCM repositories behind firewalls.

Requirements¶ ↑

This gem supports Subversion, Git, Mercurial and Bazaar. Only Subversion and Git have been extensively tested. This gem is unlikely to be supported for other SCM systems.

This gem requires the rsync command-line utilities on the local and remote hosts. It also requires either svn, git, hg or bzr on the local host, but not the remote host.

This gem is tested on Mac OS X and Linux. Windows is neither tested nor supported.

Installation¶ ↑

gem install oz_capistrano_rsync_with_remote_cache

Usage¶ ↑

To use this deployment strategy, add this line to your deploy.rb file:

set :deploy_via, :rsync_with_remote_cache

Under the Hood¶ ↑

This strategy maintains two cache directories:

  • The local cache directory is a checkout from the SCM repository. The local cache directory is specified with the :local_cache variable in the configuration. If not specified, it will default to .rsync_cache in the same directory as the Capfile.

  • The remote cache directory is an rsync copy of the local cache directory. The remote cache directory is specified with the :repository_cache variable in the configuration (this name comes from the :remote_cache strategy that ships with Capistrano, and has been maintained for compatibility.) If not specified, it will default to shared/cached-copy (again, for compatibility with remote_cache.)

Deployment happens in three major steps. First, the local cache directory is processed. There are three possibilities:

  • If the local cache does not exist, it is created with a checkout of the revision to be deployed.

  • If the local cache exists and matches the :repository variable, it is updated to the revision to be deployed.

  • If the local cache exists and does not match the <p>:repository</p> variable, the local cache is purged and recreated with a checkout of the revision to be deployed.

  • If the local cache exists but is not a directory, an exception is raised

Second, rsync runs on the local side to sync the remote cache to the local cache. When the rsync is complete, the remote cache should be an exact replica of the local cache.

Finally, a copy of the remote cache is made in the appropriate release directory. The end result is the same as if the code had been checked out directly on the remote server, as in the default strategy.

Contributors¶ ↑

Thanks to the people who submitted patches:

License¶ ↑

Copyright © 2007 - 2010 Patrick Reagan (patrick.reagan@viget.com) & Mark Cornick

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.