[chef] Re: Re: Re: Issue deploying with application cookbook - STDERR: fatal: reference is not a tree: af5c7ff84dd852cf1c0b5ca60ea92546a20dda01

[Daniel DeLeo < >]

On Tuesday, July 23, 2013 at 10:12 AM, Cassiano Leal wrote:

On July 23, 2013 at 12:58:31, Daniel DeLeo ( "> ) wrote:

On Tuesday, July 23, 2013 at 7:17 AM, Cassiano Leal wrote:

Hi,

I have a few apps that are deploying using the application cookbook (_php and _ruby). They work just fine most of the time, but every now and then when bootstrapping a new node I get these weird errors.

This is the interesting part on the debug log of the chef run:

  * deploy_revision[resourcemanager] action deploy[2013-07-23T14:08:47+00:00] INFO: Processing deploy_revision[resourcemanager] action deploy (/var/chef/cache/cookbooks/application/providers/default.rb line 122)

[2013-07-23T14:08:47+00:00] DEBUG: deploy_revision[resourcemanager] finding current git revision

[2013-07-23T14:08:47+00:00] DEBUG: deploy_revision[resourcemanager] resolving remote reference

af5c7ff84dd852cf1c0b5ca60ea92546a20dda01 refs/heads/develop

[2013-07-23T14:08:50+00:00] DEBUG: deploy_revision[resourcemanager] not creating /opt/apps/resourcemanager because it already exists

[2013-07-23T14:08:50+00:00] DEBUG: deploy_revision[resourcemanager] not creating /opt/apps/resourcemanager/shared because it already exists

[2013-07-23T14:08:50+00:00] DEBUG: deploy_revision[resourcemanager] finding current git revision

[2013-07-23T14:08:50+00:00] INFO: deploy_revision[resourcemanager] cloning repo  "> :zynkmobile/resourcemanager.git to /opt/apps/resourcemanager/shared/cached-copy

Cloning into '/opt/apps/resourcemanager/shared/cached-copy'...

    - clone from  "> :zynkmobile/resourcemanager.git into /opt/apps/resourcemanager/shared/cached-copy[2013-07-23T14:08:55+00:00] WARN: Error on deploying /opt/apps/resourcemanager/releases/af5c7ff84dd852cf1c0b5ca60ea92546a20dda01: Expected process to exit with [0], but received '128'

---- Begin output of git checkout -b deploy af5c7ff84dd852cf1c0b5ca60ea92546a20dda01 ----

STDOUT:

STDERR: fatal: reference is not a tree: af5c7ff84dd852cf1c0b5ca60ea92546a20dda01

---- End output of git checkout -b deploy af5c7ff84dd852cf1c0b5ca60ea92546a20dda01 ----

Ran git checkout -b deploy af5c7ff84dd852cf1c0b5ca60ea92546a20dda01 returned 128

[2013-07-23T14:08:55+00:00] INFO: Removing failed deploy /opt/apps/resourcemanager/releases/af5c7ff84dd852cf1c0b5ca60ea92546a20dda01

    - remove failed deploy /opt/apps/resourcemanager/releases/af5c7ff84dd852cf1c0b5ca60ea92546a20dda01[2013-07-23T14:08:55+00:00] DEBUG: Creating directory /var/chef/cache/revision-deploys

As can be seen, it finds the Git revision to deploy, clones the directory, but then cannot find the revision. I poked on the cached-copy, and it doesn’t have the branch from which I’m deploying, neither local nor origin/branch, which would certainly explain the error. What I don’t understand is why the branch is not there, since it’s definitely in the repo (and was found before, via git ls I presume).

Is there something else that should be set on the application resource so that this error would not occur?

Cheers,

--

Cassiano Leal

http://cassianoleal.com

http://twitter.com/cassianoleal

Is anyone deleting these branches, or force-pushing?

I’m not sure I understand your question. The deploy is managed 100% by the application_ruby cookbook. We’re still stabilising some of the features, so we’re deploying from the develop branch.

If you force push, commits may no longer be reachable from any branch/tag. This is an area of git that I haven't explored before, but it's described a little bit here:

http://stefan.saasen.me/articles/git-clone-in-haskell-from-the-bottom-up/

 

I managed to work around the issue manually by doing (after letting it fail with the error above):

cd /opt/apps/resourcemanager/shared/cached-copy

export GIT_SSH=/opt/apps/resourcemanager/deploy-ssh-wrapper

git fetch origin develop

And then re-running chef-client. Why hasn’t this branch been pulled from the repo in the first place?

When you do that, does it deploy the same reference it failed to deploy the first time? E.g, af5c7ff84dd852cf1c0b5ca60ea92546a20dda01 from your example?

-- 

Daniel DeLeo