Re: Capistrano - cleaning up old releases issue

[bsod99]

Sorry I should have added Capistrano version, 2.13.5 and ruby 1.8.7 (2012-02-08 patchlevel 358) [i386-cygwin]

Also, using git as scm

On Wednesday, 23 January 2013 17:26:17 UTC, bsod99 wrote:

I followed the advice in another post about how to clean up old capistrano releases, however, i've realised that the way I've implemented this has messed up the paths in my application (just on a staging site thankfully!). I am using the code below in my config/deploy/staging.rb script, but it can't be running at the correct point, as after deployment I end up with application failing as it's trying to load classes from earlier releases. If I remove the keep_releases line and the one below, and redeploy, everything works again. Has anyone come across this issue?

set :use_sudo, false
set :keep_releases, 1
after "deploy:update", "deploy:cleanup"

namespace :deploy do
  task :symlink_shared do
    // run some commands i need
  end
end

before "deploy:restart", "deploy:symlink_shared"

[Cassiano Leal]

Your symlink_shared task is probably creating symlinks to an older release anyway.

It might seem to work if you leave the old releases because the old release that it's pointing links to is still there.

Try increasing keep_releases to 2 and it'll probably still "work", but you'll have to fix the symlink_shared task anyway.

- cassiano

On Wednesday, January 23, 2013 at 15:26, bsod99 wrote:

I followed the advice in another post about how to clean up old capistrano releases, however, i've realised that the way I've implemented this has messed up the paths in my application (just on a staging site thankfully!). I am using the code below in my config/deploy/staging.rb script, but it can't be running at the correct point, as after deployment I end up with application failing as it's trying to load classes from earlier releases. If I remove the keep_releases line and the one below, and redeploy, everything works again. Has anyone come across this issue?

set :use_sudo, false
set :keep_releases, 1
after "deploy:update", "deploy:cleanup"

namespace :deploy do
  task :symlink_shared do
    // run some commands i need
  end
end

before "deploy:restart", "deploy:symlink_shared"

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

[Jonathan Rochkind]

I have not come accorss that, and am not sure what's going on.

But what is:

before "deploy:restart", "deploy:symlink_shared"

there for? What's that intended to do? Could that be causing the problem?

[Donovan Bray]

Your cleanup is running waaaay to early; it should be 

after 'deploy:restart', 'deploy:cleanup'

I would also suggest moving any symlinking to after 'deploy:update'

On Jan 23, 2013, at 9:26 AM, bsod99 <nicky.c...@gmail.com> wrote:

[Donovan Bray]

Keep releases should be 2 at minimum in my opinion

On Jan 23, 2013, at 9:26 AM, bsod99 <nicky.c...@gmail.com> wrote:

[bsod99]

Thanks for all the replies. I followed dbray's advice and kept releases at, and adjusted sequencing to:

after "deploy:update", "deploy:symlink_shared"

after "deploy:restart", "deploy:cleanup"

This seems to be working fine (and makes sense, having thought through more carefully about what each is doing)

[bsod99]

Alas, this still isn't correct - symlinking definitely a bit messed up, Can anyone see what is wrong with this staging.rb script? http://pastie.org/5927281

I must still have the order wrong...thanks for any help

[bsod99]

And checking the symlink commands being executed during deployment, I can see the current release path being used is different from the current release on the server

[Donovan Bray]

It should be #{latest_release} not #{release_path}

release_path only works during a deploy; latest_release will work all the time. 

See: 

https://github.com/capistrano/capistrano/blob/master/lib/capistrano/recipes/deploy.rb

Have you ensured that all the targets in shared exist before attempting to create the symlinks?

What isn't working about it?

Are you invoking 'cap deploy:shared_symlinks' then see my suggestion above. 

Is the cap task raising an error; post a copy of a failed run. 

Is the task executing but you just don't end up with the symlinks?

Are there files pre-existing in the release directory from checkout; you need to remove them in order to recreate them as symlinks. 

--

--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en

---

You received this message because you are subscribed to the Google Groups "Capistrano" group.

To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[bsod99]

Thanks, switched to latest_release. All the targets exist in shared, and 'cap deploy:shared_symlinks' is executing successfully during the deployment. Checking the symlinks after shows they are correct. 

The cap task isn't raising any errors. The issue is that non-shared core classes in my application are sporadically not found after a deployment, even though these files are sitting in the current release in the correct place. Also, upon re-deploying, sometimes the error can be another core class which isn't found. This just adds to the confusion in that the error isn't consistent. 

For testing, I've set keep_releases to 1 for now - on a couple of sites, deployments are working fine, but on another, I'm having the issue described above. The deployment scripts are practically identical.

[Donovan Bray]

What web server are you using. I experienced something similar with unicorn. Because of its forking the master process it had already resolved the symlink to a specific directory. Everything would work fine until the original dir the master was originally started from finally got cleaned up. 

I used to use passenger and it had similar issues until they incorporated a patch to re-evaluate the symlink for each fork. 

[bsod99]

I'm on CentOS 6, standard LAMP setup. It's really puzzling.

I wonder if I should just start afresh, as I've been messing about with the deployment script a fair bit. 

[bsod99]

Further update on this, in case it helps pinpoint the issue(s) - when an error (as described above) arises after a deployment, if I remove the releases/cached-copy/log/pids folders and run deploy:setup and deploy, my sites work correctly. 

[Donovan Bray]

Inspecting the contents and comparing the pids specified in the files vs the ones that are running may give you clues to the problem. 

Make a note of your pids pre-deploy; do the deploy then compare the pids previous; to the current pids; and to the pids in the directory. 

[bsod99]

Sorry for the delay on this - should there be something in the shared/pids folder? mine are always empty (running ls -a). One thing which may or may not be linked to the issue, is that capistrano is creating a "system" folder, in shared. The framework I use for my sites also has a system folder, which contains all the core framework files which are never edited. So my releases folder would have the following for example:

app_public

app_admin

public_html

system

modules

And my shared folder would have

app_public -> containing some non-versioned config stuff symlinked to currnet

app_admin -> same for this

public_html -> same 

cached-copy -> capistrano

log -> capistrano

pids -> capistrano

system -> capistrano

[Donovan Bray]

You will need to override the cap variable shared_children in order to omit 'system' from symlink activities during deploy. 

[bsod99]

If it helps anyone having this issue, I started using railsless for deploy, along with ThePixelDeveloper's Capistrano recipe at https://gist.github.com/ThePixelDeveloper/211105