Carview!

CARVIEW

MOTORHOMES

Select Language

HTTP/2 302 server: nginx date: Sat, 19 Jul 2025 18:42:26 GMT content-type: text/plain; charset=utf-8 content-length: 0 x-archive-redirect-reason: found capture at 20090206150640 location: https://web.archive.org/web/20090206150640/https://github.com/guides/deploying-with-capistrano.atom server-timing: captures_list;dur=0.788979, exclusion.robots;dur=0.026193, exclusion.robots.policy;dur=0.011589, esindex;dur=0.014858, cdx.remote;dur=39.482161, LoadShardBlock;dur=245.947966, PetaboxLoader3.datanode;dur=57.357959, PetaboxLoader3.resolve;dur=112.626044 x-app-server: wwwb-app211 x-ts: 302 x-tr: 374 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0 set-cookie: SERVER=wwwb-app211; path=/ x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() HTTP/2 200 server: nginx date: Sat, 19 Jul 2025 18:42:27 GMT content-type: application/atom+xml; charset=utf-8 content-length: 102590 x-archive-orig-server: nginx/0.6.31 x-archive-orig-date: Fri, 06 Feb 2009 15:06:39 GMT x-archive-orig-connection: close x-archive-orig-status: 200 OK x-archive-orig-x-runtime: 980ms x-archive-orig-etag: "1679376cbb1371ce6f25f5b6e7844651" x-archive-orig-cache-control: private, max-age=0, must-revalidate x-archive-orig-content-length: 102590 cache-control: max-age=1800 x-archive-guessed-content-type: text/xml x-archive-guessed-charset: utf-8 memento-datetime: Fri, 06 Feb 2009 15:06:40 GMT link: ; rel="original", ; rel="timemap"; type="application/link-format", ; rel="timegate", ; rel="first memento"; datetime="Fri, 06 Feb 2009 15:06:40 GMT", ; rel="memento"; datetime="Fri, 06 Feb 2009 15:06:40 GMT", ; rel="next memento"; datetime="Wed, 08 Apr 2009 18:28:20 GMT", ; rel="last memento"; datetime="Wed, 08 Apr 2009 18:28:20 GMT" content-security-policy: default-src 'self' 'unsafe-eval' 'unsafe-inline' data: blob: archive.org web.archive.org web-static.archive.org wayback-api.archive.org athena.archive.org analytics.archive.org pragma.archivelab.org wwwb-events.archive.org x-archive-src: 52_8_20090206135335_crawl103-c/52_8_20090206150502_crawl101.arc.gz server-timing: captures_list;dur=0.498129, exclusion.robots;dur=0.018101, exclusion.robots.policy;dur=0.008525, esindex;dur=0.009514, cdx.remote;dur=31.093186, LoadShardBlock;dur=208.277872, PetaboxLoader3.datanode;dur=122.071028, PetaboxLoader3.resolve;dur=514.735945, load_resource;dur=724.970467 x-app-server: wwwb-app211 x-ts: 200 x-tr: 1003 server-timing: TR;dur=0,Tw;dur=0,Tc;dur=0 x-location: All x-rl: 0 x-na: 0 x-page-cache: MISS server-timing: MISS x-nid: DigitalOcean referrer-policy: no-referrer-when-downgrade permissions-policy: interest-cohort=() accept-ranges: bytes tag:github.com,2008:/guides/deploying-with-capistrano GitHub Guides - Deploying with Capistrano 2008-12-27T14:57:13-08:00 tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-12-27T14:57:13-08:00 Deploying with Capistrano - version 24 Sat Dec 27 14:57:13 -0800 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. N.B. GitHub doesn’t allow the same public key to be assigned to more than one account. If you would like multiple users to be able to deploy from the same repo you’ll probably want to add the deployer’s public key as a Deploy Key for the repo in question. To do this make sure you’re logged into GitHub as the repo administrator, edit the repo and go to the Admin tab. There you’ll be able to add the deploy key. Now for the fun part, configuring <a href="https://www.capify.org/">Capistrano</a>. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p@ssw0rd" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> ssh_options[:forward_agent] = true </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> Or use the following line for newer versions of Capistrano: <pre class="console">set :branch, "master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. cadorn tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-07-23T14:23:42-07:00 Deploying with Capistrano - version 23 Wed Jul 23 14:23:42 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. N.B. GitHub doesn’t allow the same public key to be assigned to more than one account. If you would like multiple users to be able to deploy from the same repo you’ll probably want to add the deployer’s public key as a Deploy Key for the repo in question. To do this make sure you’re logged into GitHub as the repo administrator, edit the repo and go to the Admin tab. There you’ll be able to add the deploy key. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p@ssw0rd" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> ssh_options[:forward_agent] = true </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> Or use the following line for newer versions of Capistrano: <pre class="console">set :branch, "master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. jatkins tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-07-18T10:07:18-07:00 Deploying with Capistrano - version 22 Fri Jul 18 10:07:18 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. N.B. GitHub doesn’t allow the same public key to be assigned to more than one account. If you would like multiple users to be able to deploy from the same repo you’ll probably want to add the deployer’s public key as a Deploy Key for the repo in question. To do this make sure you’re logged into GitHub as the repo administrator, edit the repo and go to the Admin tab. There you’ll be able to add the deploy key. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> ssh_options[:forward_agent] = true </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> Or use the following line for newer versions of Capistrano: <pre class="console">set :branch, "master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. febuiles tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-07-15T04:29:19-07:00 Deploying with Capistrano - version 21 Tue Jul 15 04:29:19 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. N.B. GitHub doesn’t allow the same public key to be assigned to more than one account. If you would like multiple users to be able to deploy from the same repo you’ll probably want to add the deployer’s public key as a Deploy Key for the repo in question. To do this make sure you’re logged into GitHub as the repo administrator, edit the repo and go to the Admin tab. There you’ll be able to add the deploy key. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> ssh_options[:forward_agent] = true </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. livework tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-07-12T13:51:07-07:00 Deploying with Capistrano - version 20 Sat Jul 12 13:51:07 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> ssh_options[:forward_agent] = true </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. nbibler tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-07-12T13:50:10-07:00 Deploying with Capistrano - version 19 Sat Jul 12 13:50:10 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> ssh_options[:forward_agent] = true </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. nbibler tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-07-12T13:49:09-07:00 Deploying with Capistrano - version 18 Sat Jul 12 13:49:09 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> ssh_options[:forward_agent] = true </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. nbibler tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-07-12T06:34:49-07:00 Deploying with Capistrano - version 17 Sat Jul 12 06:34:49 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> set :ssh_options, { :forward_agent => true } </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> <blockquote> Older versions of git (e.g. 1.4.4.2) don’t support -q on git checkout command. This will cause your deployment to fail by default. To fix either upgrade git or do: <code> set :scm_verbose, true </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. cjwoodward tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-05-21T16:32:35-07:00 Deploying with Capistrano - version 16 Wed May 21 16:32:35 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> set :ssh_options, { :forward_agent => true } </pre> <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. theill tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-05-21T16:31:59-07:00 Deploying with Capistrano - version 15 Wed May 21 16:31:59 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> If you’re using your own private keys for git you might want to tell Capistrano to use agent forwarding with this command <pre class="console"> set :ssh_options, { :forward_agent => true } </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. theill tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-05-11T09:29:48-07:00 Deploying with Capistrano - version 14 Sun May 11 09:29:48 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <blockquote> I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> </blockquote> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. adamcooke tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-05-11T09:27:27-07:00 Deploying with Capistrano - version 13 Sun May 11 09:27:27 -0700 2008 It would probably be a good idea to add a special user on your server(s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. adamcooke tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-05-07T11:55:17-07:00 Deploying with Capistrano - version 12 Wed May 07 11:55:17 -0700 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. I tried using “origin/master” but I get the following error from Capistrano. Therefore I use `set :branch, “master”` instead. -DJ <code> /opt/local/lib/ruby/gems/1.8/gems/capistrano-2.3.0/lib/capistrano/recipes/deploy/scm/git.rb:217:in `query_revision': Unable to resolve revision for origin/master (RuntimeError) </code> You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. <h4>Known Hosts List</h4> Note: the first time I tried to deploy, I got a failure, apparently because Capistrano wasn’t prompting with this message: <pre class="console"> The authenticity of host 'github.com (65.74.177.129)' can't be established. RSA key fingerprint is .... Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'github.com,65.74.177.129' (RSA) to the list of known hosts. </pre> So I opened up a terminal separate from Capistrano and pulled my repo, added github.com to the list of known hosts. My next Cap deploy worked. djwonk tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-05-02T13:56:53-07:00 Deploying with Capistrano - version 11 Fri May 02 13:56:53 -0700 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it to your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. bryckbost tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-03-31T18:39:38-07:00 Deploying with Capistrano - version 10 Mon Mar 31 18:39:38 -0700 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it you your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. <h4>Submodules</h4> <pre class="console">set :git_enable_submodules, 1</pre> If you’re using git’s submodule support for edge rails or merb, set this guy to make sure the submodules “git” checked out. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. vanpelt tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-03-09T15:23:44-07:00 Deploying with Capistrano - version 9 Sun Mar 09 15:23:44 -0700 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it you your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre class="console"> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre class="console">set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre class="console">set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre class="console">set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. mojombo tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-03-09T08:29:51-07:00 Deploying with Capistrano - version 8 Sun Mar 09 08:29:51 -0700 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it you your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre>set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre>set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre>set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. That’s it folks, easy as pie. <h4>Migrating from SVN</h4> Migrating from SVN-based deploys? <a href="https://groups.google.com/group/github/browse_frm/thread/c5d2620c541e4e1a">Check this thread</a> if you run into any problems. defunkt tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-01-31T10:34:06-08:00 Deploying with Capistrano - version 7 Thu Jan 31 10:34:06 -0800 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it you your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. <h4>Set Branch</h4> <pre>set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Remote Cache</h4> <pre>set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre>set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. That’s it folks, easy as pie. schacon tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-01-31T10:33:35-08:00 Deploying with Capistrano - version 6 Thu Jan 31 10:33:35 -0800 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it you your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. You may also wish to use one of the following options if your git repo is very large – otherwise each deploy will do a full repository clone every time. <h4>Set Branch</h4> <pre>set :branch, "origin/master"</pre> This will specify the branch that gets checked out for the deployment. <h4>Remote Cache</h4> <pre>set :deploy_via, :remote_cache</pre> Remote caching will keep a local git repo on the server you’re deploying to and simply run a fetch from that rather than an entire clone. This is probably the best option and will only fetch the differences each deploy <h4>Shallow Clone</h4> <pre>set :git_shallow_clone, 1</pre> Shallow cloning will do a clone each time, but will only get the first tree, not all the parents trees, too. This makes it a bit closer to how an svn checkout works, but be careful when using with the <code>set :branch</code> option, because it wont work unless the shallow clone number is big enough to encompass the branch you’ve specified. That’s it folks, easy as pie. schacon tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-01-29T11:45:00-08:00 Deploying with Capistrano - version 5 Tue Jan 29 11:45:00 -0800 2008 It would probably be a good idea to add a special user on your server('s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see <a href="https://github.com/guides/providing-your-ssh-key">Providing Your SSH Key</a> ), and add it you your github account. You may also want to add your personal public key to this new user's <code>~/.ssh/authorized_keys</code> to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the <code>:pty</code> option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the <code>:repository</code> option to your github clone URL. Set the <code>:passphrase</code> to the one you generated in the initial step, and set <code>:user</code> to the one you just created. That’s it folks, easy as pie. vanpelt tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-01-29T11:42:03-08:00 Deploying with Capistrano - version 4 Tue Jan 29 11:42:03 -0800 2008 It would probably be a good idea to add a special user on your server(’s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see https://github.com/guides/providing-your-ssh-key ), and add it you your github account. You may also want to add your personal public key to this new user’s ~/.ssh/authorized_keys to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <pre> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </pre> We need to turn on the :pty option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the :repository option to your github clone URL. Set the :passphrase to the one you generated in the initial step, and set :user to the one you just created. That’s it folks, easy as pie. vanpelt tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-01-29T11:38:50-08:00 Deploying with Capistrano - version 3 Tue Jan 29 11:38:50 -0800 2008 It would probably be a good idea to add a special user on your server(’s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see https://github.com/guides/providing-your-ssh-key ), and add it you your github account. You may also want to add your personal public key to this new user’s ~/.ssh/authorized_keys to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <code> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </code> We need to turn on the :pty option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the :repository option to your github clone URL. Set the :passphrase to the one you generated in the initial step, and set :user to the one you just created. That’s it folks, easy as pie. vanpelt tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-01-29T11:32:45-08:00 Deploying with Capistrano - version 2 Tue Jan 29 11:32:45 -0800 2008 It would probably be a good idea to add a special user on your server(’s) specifically for deployment. Once created, make sure to generate a public key for that SOB (see https://github.com/guides/generating-ssh-keys), and add it you your github account. You may also want to add your personal public key to this new user’s ~/.ssh/authorized_keys to ease deployment. Now for the fun part, configuring Capistrano. Here are the 5 most notable Capistrano config options: <code> default_run_options[:pty] = true set :repository, "git@github.com:vanpelt/rails-app.git" set :scm, "git" set :scm_passphrase, "p00p" #This is your custom users password set :user, "deployer" </code> We need to turn on the :pty option because it would seem we don’t get the passphrase prompt from git if we don’t. Point the :repository option to your github clone URL. Set the :passphrase to the one you generated in the initial step, and set :user to the one you just created. That’s it folks, easy as pie. vanpelt tag:github.com,2008:Guide/5 2008-01-29T11:21:12-08:00 2008-01-29T11:21:12-08:00 Deploying with Capistrano - version 1 Tue Jan 29 11:21:12 -0800 2008 vanpelt

Original Source | Taken Source