Rollback deletes wrong release

[booyah]

I've been introduced to Capistrano by a colleague and must say i'm
loving it, however, I'm seeing some strange behaviour with the
rollback task:

for example, lets say I have 3 releases with 1 being the newest and 3
being the oldest. If I do cap deploy:rollback I would expect it to
roll back from release 1 to release 2 and release 1 would be deleted.

But what actually happens is that it rolls back from release 1 to
release 2 and release _3_ is deleted, even though the process of
recreating the symlink to the previous release (2) is done correctly.

any help is much appreciated...

[Lee Hambley]

Are you using file-based rails caching? We have an open bug for that, in a nutshell the `ls -xt` command we use, lists them in the `wrong` order if you are using file caching.

( this could be an easy fix, but how should we approach it? – thus we haven't )

-- Lee Hambley

Twitter: @leehambley | @capistranorb

[booyah]

I've come to the same conclusion. I'm not using file-based rails
caching. I'm just using it for deploying a PHP site and have
overridden a lot of the rails specific tasks in deploy.

The ordering of the releases from 'ls -xt' is the problem, but the
reason I think they're in the wrong order is because of the
timestamps. While the deploy task is running I can see that the new
release folder has correct timestamp ie now, but at the end of the
deploy task 'something' is setting the modification date of ALL the
release folders to the same timestamp, and it's completely wrong
(12-24 hours ago). Then the deploy:rollback gets it completely wrong
and the problem occurs.

Can you confirm if you're seeing the same behaviour?

I'm still trying to work out exactly where it's going wrong. I'm
trying touching release folders using before_ and after_ but still
haven't got a working solution.

[booyah]

I think I've been able to solve it by touched the latest release
folder after update_code:

task :after_update_code, :roles => [:web] do
# Sleep may not be needed
run "sleep 1"
run "touch #{latest_release}"
end

I deleted all releases and did a number of deploys and rollbacks and
they all worked ok. By setting the timestamp at the end of the
update_code task, the ls -xt in rollback returns the releases in the
right order.

If anyone else is having this problem please let me know if this fix
works for you too.

[booyah]

nb. I've found that run'ing any command that modifies any release
folder or its contents will cause the dodgy timestamp to appear
again. So be careful what you do in a :before_update_code task...

[Lee Hambley]

The solution is to figure out the way that works for your infrastructure to `ls` them in the right way, then you can overload this default:

set(:releases)          { capture("ls -xt #{releases_path}").split.reverse }

Defined in:
http://github.com/capistrano/capistrano/blob/master/lib/capistrano/recipes/deploy.rb#L53

You must use set() not _cset() when you redefine this, but you should figure one that works for your environment - we need to address this in the master (next bug fix release) Current ticket is at:

• https://capistrano.lighthouseapp.com/projects/8716/tickets/88-getting-the-newest-directory