Detect changed repo_url

[marcovtwout]

Using svn, when I change the repo_url, the clone on the server is not changed and the old version remains.

The solution is simple: when the repo_url changes, I expect the repo clone to be deleted and checked out again.

[marcovtwout]

I found a plugin that solves this, but I think this should be core behavior: https://gist.github.com/bluefuton/982691

[leehambley]

If you prepare a PR with tests for incorporating this behaviour into Capistrano, we'd be glad. Actually Git suffers the same problem sometimes, and it can be very confusing for people.

[marcovtwout]

Implementing that properly is a bit out of my reach I'm afraid (I'm new to Ruby development).

[mattbrictson]

Even if we're not building the feature right now, it could be useful to discuss it a little more, for future reference.

The Gist you mentioned seems to delete the entire repository checkout if it finds the repo_url has changed, so that the repo can be re-cloned. I guess that works, but I feel nervous about Capistrano doing a wholesale delete with rm -rf automatically without user confirmation.

Maybe a safer solution is for Capistrano to abort with an error message like this:

It seems that your repo_url has changed since your last deployment.
Run `cap production [scm]:reset` to delete Capistrano's cache and fetch the new repo_url.

And then an e.g. svn:reset, git:reset, etc. would delete the checkout and do a fresh clone.

[leehambley]

I'm about to support a customer (this week) who has a similar problem for the first time, I'll see if I can come up with the bones of a sane task to use as a reference for discussing this further

[mattbrictson]

Possibly consider addressing this as part of the same solution: #1482 (in this case repo_url hasn't changed, but cached credentials have gone stale).

[leehambley]

I'm about to support a customer (this week) who has a similar problem for the first time, I'll see if I can come up with the bones of a sane task to use as a reference for discussing this further

Ran into some problems, so we nuked the repo - since we "own" repo in the :deploy_to it seems relatively harmless, but I do think we should do as you suggested, and prompt.

[mattbrictson]

Although a problem with prompting is if you are running Capistrano in non-interactive settings, like CI…

[marcovtwout]

since we "own" repo in the :deploy_to it seems relatively harmless

Yes, I don't think prompting is needed, no different to purging an old release.

[leehambley]

I wonder what the correct target to compare to should be? I wonder if the output of git config remote.origin.url compared with the :repo_url variable (with interpolated usernames/passes) would suffice, or if Git has a plumbing command we're supposed to use for that.

[marcovtwout]

A more generic solution for any SCM could be to compute a hash based on relevant config vars (like repo_url, branch), store it in repo directory, and use it to detect changed configuration.

[leehambley]

That's a decent idea actually, it might mean we could cache the repo in repo_cahce/:the_hash_from_connection_params[0..10] or something, to solve the problem of whether or not to delete user data?

[mattbrictson]

we could cache the repo in repo_cahce/:the_hash_from_connection_params[0..10] or something, to solve the problem of whether or not to delete user data

Brilliant! I say we give that a shot.

[leehambley]

Good. So if I get chance (Each Tuesday morning, I have time) 2016-02-26 I'll take a punt at this, and we can maybe put a PR on here too.

[marcovtwout]

If I understand you correctly, you want to use the hash to create subdirectories within repo and put the checkout/clone there. Wouldn't this make it a bit less transparent to the user ("which repo subdirectory is capistrano currently using?", and maybe harder for backward compatiblity? (for example, plugins depending on a fixed repo directory).

Just using the hash to purge the repo directory when changed, should also be enough, and easier to implement. :)

[mattbrictson]

Wouldn't this make it a bit less transparent to the user ("which repo subdirectory is capistrano currently using?", and maybe harder for backward compatiblity?

True.

Just using the hash to purge the repo directory when changed, should also be enough, and easier to implement.

Yes, I think you are probably right.

[cmrd-senya]

I would like to add, that sometimes you have change the repo url, but it is just another clone of the same repo (like you point to a fork instead of main repo on github). In this case it would be nice to add the new repository as a remote to an existing repository instead of rm -rf && git clone, because it would be notably speed up deployment of large applications.

[mingan]

We've recently migrated our repository, changed the :repo_url option and got bitten by this problem. This issue is old and there doesn't seem to be any progress. Shouldn't it be at least documented? Is this file the right place for a warning?

[will-in-wi]

@mingan: It would probably be a good idea to at least have a note for the time being in the file you referenced, probably in the :repo_url section. Would you be willing to put together a PR for this?

Thanks!

[mattbrictson]

FYI, this issue has been fixed for git (but not other SCMs) in Capistrano 3.7.2. See #1826.

[ghost]

It seems this issue is now also fixed for svn? 8cbe893

[mattbrictson]

@marcovtwout-tremani Yes, it should be fixed for svn in capistrano 3.8.0. I'll close the issue.