The deploy and deploy_revision resources have inconsistent behavior

Hi Mike - I'm using chef for deployment both in revision and timestamp modes (on different projects) and I haven't seen such problem. I've tried to reproduce this problem and wasn't able to do it. Also I've quickly went through the code and deploy::revision provider uses git provider in the same way as parent deploy provider - it respects provided user when runs git command.

Could you provide more information and paste full log.

Maybe problem somehow connected with git_ssh_wrapper?

Hi Igor,

Thanks for taking the time.

I've successfully pared down the code to a gist, located here: https://gist.github.com/2238068
I don't include my keys, for obvious reasons.

Outputs of the two differing runs is here: https://gist.github.com/2238115

Again, this is shown by a misconfiguration of permissions. Fixing them to be the correct allows for the deploy_revision to work correctly, but I would expect that they both fail if the key permissions are misconfigured.

Mike, I'll take a look into logs tomorrow but as sidenote/workaround - why not using ssh forwarding? It works only if you're not running chef as daemon - but if you're running it only when you're doing deploys it would work well. Also as a free benefit - it would give ability to do deployment only to people who has access both to server and repo.

We're looking at a workflow where someone commits into the repo, and this change gets auto-deployed to the target server, with minimal to no intervention, since Chef is running as a daemon.

But that's beyond the error shown here. I'm looking for consistent resource behavior - i.e. if one resource fails due to misconfigured private key permissions, then they both should.

I've found and fixed the issue. The problem was in order of resources loading. In current implementation scm provider was loaded just before updating the cached_repo (deploy.rb:208) it works fine for timestamped deploy but in revision based deploy the first interaction with scm_provider happens before the scm provider is loaded - in revision_slug method which is called from load_current_resource of deploy provider. Which I think caused described issues with permissions.

I have fixed this behavior by moving `@scm_provider.load_current_resource` call to `load_current_resource` method of deploy provider. I think it would help prevent such things in future, so providers based on deploy provider will not have to worry about whether the resource from parent class is loaded and ready to use.

Link to pull request. Specs provided.

Marked to be merged.

Thanks Igor!

(merged to master, ha!)