Capistrano deploy fails after I changed the repository URL

Question

I have a simple deployment via capistrano from a Git repository. At first I was deploying form GitHub, everything worked just fine. But then I moved my repository to BitBucket and now I'm getting

fatal: Could not parse object '9cfb...'.

The problem goes away once I change

set :deploy_via, :remote_cache

to

set :deploy_via, :copy

but that doesn't fix the problem, it only bypasses it. Is there any way I can tell capistrano to just drop the old cache?

Answer 1

Capistrano 2.X

Delete and re-clone the repo using the new address:

cd $deploy_to/shared
rm -rf cached-copy
git clone ssh://[email protected]/new/repo.git cached-copy

Modify your config/deploy.rb to use the new repo:

set :repository, "ssh://[email protected]/new/repo.git"
set :scm, :git
set :deploy_via, :remote_cache

Deploy again:

cap deploy

Capistrano 3.X

1. Remove the $deploy_to/repo directory
2. Modify your config/deploy.rb (same as 2.X)
3. cap deploy

Answer 2

I gotta say I’m not sure, since I haven’t been able to test this but this should work:

cap deploy:cleanup -s keep_releases=0

Since it wipes every release (cache) from the server.

Apparently you will also need to remove shared/cached-copy, because this doesn’t seem to be cleaned by the Capistrano call above according to the comment below.

Answer 3

Capistrano 2 and below

SSH to your server and update the repo in ./shared/cached-copy/.git/config of the deployment folder, or just remove the ./shared/cached-copy

Capistrano 3 and above

SSH to your server and update the repo in ./repo/config of the deployment folder.

Check Fixing Capistrano 3 deployments after a repository change

Answer 4

I solved this with the following in deploy.rb:

namespace :deploy do
  task :cope_with_git_repo_relocation do
    run "if [ -d #{shared_path}/cached-copy ]; then cd #{shared_path}/cached-copy && git remote set-url origin #{repository}; else true; fi"
  end
end
before "deploy:update_code", "deploy:cope_with_git_repo_relocation"

It makes deploys a little slower, so it's worth removing once you're comfortable that all your deploy targets have caught up.