[Capistrano] Re: Error while deploying
Anil, Your server has an older version of Git installed that does not honor the -q flag. You should be able to set scm_verbose to false to work around this if you don't want to upgrade Git: set :scm_verbose, false -Mark On Sun, Jun 29, 2008 at 3:38 PM, Anil Wadghule <[EMAIL PROTECTED]> wrote: > Hi, > > When I commented line > > #set :deploy_via, :remote_cache > > I was able to do cap deploy successfully, But > > but it said "Initialized empty Git repository in > /home/anil/public_html/planetrails.digitalcodes.org/releases/20080629193725/.git/" > > I think its wrong to happen. > > -- Anil > > On Mon, Jun 30, 2008 at 12:00 AM, Anthony Ettinger <[EMAIL PROTECTED]> > wrote: >> >> it appears that "git reset" needs to be "git-reset" >> >> >> >> On Sun, Jun 29, 2008 at 8:44 AM, Anil Wadghule <[EMAIL PROTECTED]> >> wrote: >> > Hi, >> > >> > Deployment was working fine until last week. I have updated to newer >> > version >> > of capistrano(capistrano (2.4.3, 2.1.0)). May be I because of upgrade of >> > capistrano version, getting following error. >> > >> > Could you help me out to resolve this error. >> > >> > anil-wadghules-computer:~/code/rails/planet anilwadghule$ cap deploy >> > * executing `deploy' >> > * executing `deploy:update' >> > ** transaction: start >> > * executing `deploy:update_code' >> > updating the cached checkout on all servers >> > * executing "if [ -d >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > ]; >> > then cd >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > && >> > git fetch -q origin && git reset -q --hard >> > bdfe1e7c1ac919875e727be63ebd177f3e27d01a; else git clone -q >> > git://github.com/anildigital/planet.git >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > && cd >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > && >> > git checkout -q -b deploy bdfe1e7c1ac919875e727be63ebd177f3e27d01a; fi" >> > servers: ["planetrails.digitalcodes.org"] >> > [planetrails.digitalcodes.org] executing command >> > ** [planetrails.digitalcodes.org :: err] Usage: /usr/bin/git-reset >> > [--mixed >> > | --soft | --hard] [] [ [--] ...] >> > command finished >> > *** [deploy:update_code] rolling back >> > * executing "rm -rf >> > >> > /home/anil/public_html/planetrails.digitalcodes.org/releases/20080629154059; >> > true" >> > servers: ["planetrails.digitalcodes.org"] >> > [planetrails.digitalcodes.org] executing command >> > command finished >> > command "if [ -d >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > ]; >> > then cd >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > && >> > git fetch -q origin && git reset -q --hard >> > bdfe1e7c1ac919875e727be63ebd177f3e27d01a; else git clone -q >> > git://github.com/anildigital/planet.git >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > && cd >> > /home/anil/public_html/planetrails.digitalcodes.org/shared/cached-copy >> > && >> > git checkout -q -b deploy bdfe1e7c1ac919875e727be63ebd177f3e27d01a; fi" >> > failed on planetrails.digitalcodes.org >> > >> > -- >> > Anil >> > http://anilwadghule.com >> > > >> > >> >> >> >> -- >> Anthony Ettinger >> 408-656-2473 >> http://anthony.ettinger.name >> >> > > > > -- > Anil > http://anilwadghule.com > > > --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Does 'cap rollback' do anything with migrations?
On Oct 2, 2007, at 11:13 PM, chris johnson wrote: > I was wondering if calling 'cap rollback' does anything with > migrations? I ask because if you rollback code to a previous version, > and you don't touch the database, this presents and obvious problem of > consistency. Rollback does not reverse migrations, I think the prevailing opinion is that it's too dangerous to automate. Add to that the possibility that there are irreversible changes, and it's far safer to do any reverse migrations manually that via Capistrano. -Mark --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Cap edit?
On Jul 19, 2007, at 6:57 PM, Tim Carey-Smith wrote: > > * Jamis Buck <[EMAIL PROTECTED]> [2007-07-19 15:41:42 -0600]: > >> Neat idea, Mat. I don't know of anything that currently does that, >> but >> if you find a nice way to implement it, I'd certainly consider adding >> it to cap. Bonus points if it works on Windows, too. :) > > I hacked up a simple implementation. > It isn't very clean, but functions. > Available at: http://pastie.caboo.se/80481 Oh, that looks much better than my hack. Nice job, Tim. -Mark --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Cap edit?
The bonus points just weren't worth the extra work over my ugly
hack. :) Be careful, this is extremely minimally tested. If anyone
wants to clean this up and submit it for inclusion in Capistrano,
feel free.
require 'fileutils'
def files_match(dir)
first = nil
`sum #{dir}/*`.split("\n").each do |line|
curr = line.split[0]
first ||= curr
return false if first != curr
end
true
end
task :edit do
tmpdir = File.join((ENV['TMPDIR'] || '/tmp'), "cap_edit.#{$
$.to_s}", '')
Dir.mkdir(tmpdir, 0700)
begin
first_host = nil
execute_on_servers do |servers|
servers.each do |srv|
first_host ||= srv.host
sftp = sessions[srv].sftp
sftp.connect unless sftp.state == :open
sftp.get_file ENV['FILE'], File.join(tmpdir, srv.host)
end
end
if files_match(tmpdir)
edit_path = File.join(tmpdir, first_host)
if system("#{ENV['EDITOR']} #{edit_path}")
data = File.open(edit_path).readlines
put(data, ENV['FILE'])
else
logger.debug "Editor command failed."
end
else
logger.info "Remote files don't match, skipping edit."
end
ensure
FileUtils.rm_rf(tmpdir)
end
end
On Jul 19, 2007, at 5:41 PM, Jamis Buck wrote:
>
> Neat idea, Mat. I don't know of anything that currently does that, but
> if you find a nice way to implement it, I'd certainly consider adding
> it to cap. Bonus points if it works on Windows, too. :)
>
> - Jamis
>
> On 7/19/07, Mat Schaffer <[EMAIL PROTECTED]> wrote:
>>
>> Just had an idea flash, that might already exist and would be way
>> cool if it did.
>>
>>> cap edit FILE=/etc/hosts ROLES=web
>>
>> (1) check that the file is identical on all hosts
>> (2) get and open the file with $EDITOR
>> (3) upload the altered file
>>
>> I don't know about you, but that gives me goosebumps :)
>>
>> -Mat
>>
>>>
>>
>
> >
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: 'release_path' or 'current_dir'?
On May 20, 2007, at 2:05 AM, andreux wrote: > > I'm a little confused about the difference between the 'release_path' > and 'current_dir' variables. Could someone explain the difference? > Assuming you have your :deploy_path set to '/u/apps', and your application name is 'example': :current_path = /u/apps/example/current :release_path = /u/apps/example/releases/2007052012345678 Anything that you need to do in tasks that happen before the symlink task will need to use release_path since current_path will still be pointing to your last deployed release, and not the one you're deploying now. -Mark --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Capistrano 2 sanity tip.
As a way of managing my sanity while keeping Capistrano 1 and 2 installed for different projects, I created a few Bash aliases to make the process more obvious. My "cap" wrapper script is installed in / opt/local/bin/cap, and I've setup the following: alias cap='echo "You must run either cap1 or cap2."' alias cap1='/opt/local/bin/cap _1.4.1_' alias cap2='/opt/local/bin/cap' Some examples of what you see on the command line, though it should be pretty obvious: >> mark @ strongbad [ /Users/mark ] % cap You must run either cap1 or cap2. >> mark @ strongbad [ /Users/mark ] % cap1 --version Capistrano v1.4.1 >> mark @ strongbad [ /Users/mark ] % cap2 --version Capistrano v1.99.0 Hopefully that'll be useful for other people who are as easily confused as I am. :) -Mark --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Deploy to two servers, one in dev mode, one in production
On Mar 16, 2007, at 1:58 PM, James Hughes wrote:
> Hello,
>
> I have an app that is deploying to a single server using a two mongrel
> cluster ala Coda Hale's instructions[1].
>
> I want to add another server to the recipe, with a twist. So far I
> have the following:
>
> role :web, "hudson" #, "cartier"
> role :app, "hudson" #, "cartier"
>
> (cartier is commented out for now, but eventually I want to deploy to
> both of these. The twist is that I'd like to start the mongrels on
> hudson in development mode, and cartier in production mode to ensure
> they hit different backends (LDAP, not db, btw). I see that there is
> an environment setting in mongrel_cluster.yml, but this looks like a
> blanket setting for all deployment servers. Any way to delineate the
> environment per server?
You might try something along these lines:
task :restart do
sudo "#{current_path}/script/mongrel_wrapper cluster::restart"
end
With a mongrel_wrapper script that looks like:
8< ---
#!/bin/sh
if [ `hostname` == 'hudson' ]; then
RAILS_ENV=development
else
RAILS_ENV=production
fi
export RAILS_ENV
mongrel_rails $1
8< ---
You will want to not have the production variable set in
mongrel_cluster.yml in this case, since you'll be getting it from the
environment instead. Also note that I haven't tested this, but
something along these lines ought to get the job done for you.
Another alternative is to setup something like runit to supervise
your Mongrels. If you do that, you can have different run scripts on
each host that control the environment that each Mongrel process is
started with, among other things.
-Mark
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: update_code
On Jan 8, 2007, at 6:51 PM, [EMAIL PROTECTED] wrote: Has anyone configured capistrano such that code is always pushed to, and never pulled by, the deployment target machines? How did you do it? KM, Have a peek at the list archives, there has been quite a bit of discussion about this recently. In particular, if you're using Subversion, the thread at the following URL will be of interest to you: http://groups.google.com/group/capistrano/browse_frm/thread/ a23214d4458a4a3b/57cf99c1b33b5e6a?lnk=raot#57cf99c1b33b5e6a -Mark smime.p7s Description: S/MIME cryptographic signature
[Capistrano] Re: New to Capistrano... Few fundamental questions
On Oct 26, 2006, at 1:46 PM, E.B. Farnum wrote: Suppose I let capistrano have it's default deployment directory and it put all the releases in /u/apps/flippy. Could I remove my /var/www/flippy directory and symlink /var/www/flippy to /u/apps/flippy/current? Or could there be issues doing that? Thanks for being a sounding board. I'm assuming you're talking about something like: ln -s /u/apps/flippy/current /var/www/flippy There shouldn't be any issues doing something like that. Even though what the /u/apps/flippy/current is linked to will change every time you deploy, you can depend on /u/apps/flippy/current pointing to the active revision. -Mark smime.p7s Description: S/MIME cryptographic signature
