search

effkay / blazing

painless git push deployments for everyone
MIT License
80 stars 12 forks source link

problems in bundle install with new gems #67

Closed pedroaxl closed 12 years ago

pedroaxl commented 12 years ago

Hello,

I am having this problem when I want to deploy an application with changes (normally new gems) on Gemfile. I don't know if is there anything related to checking out a gem from a git source (like: gem 'subdomain-fu', git: "git://github.com/nhowell/subdomain-fu.git").

This is the post-hook log: remote: ------> [blazing] Loading rvm string: ruby-1.9.2@m3 remote: Using /home/m3/.rvm/gems/ruby-1.9.2-p320 with gemset m3 remote: ------> [blazing] Bundling gems remote: fatal: Not a git repository: '.git' remote: fatal: Not a git repository: '.git' remote: Git error: command git fetch --force --quiet --tags 'git://github.com/nhowell/subdomain-fu.git' "refs/heads/*:refs/heads/*" in directory /home/mailee3/maileebeta.me/vendor/bundle/ruby/1.9.1/cache/bundler/git/subdomain-fu-182bd392a95d6084e6c0cb38e84c085d88257aed has failed. remote: If this error persists you could try removing the cache directory '/home/m3/mbeta.me/vendor/bundle/ruby/1.9.1/cache/bundler/git/subdomain-fu-182bd392a95d6084e6c0cb38e84c085d88257aed'

Maybe this is a problem with bundle and there is nothing to do with blazing, but if I ssh to the server and run bundle --deployment --quiet --without development test (the same command that is on the post-receive hook), everything goes fine.

effkay commented 12 years ago

Hi there

I think what you are experiencing is what I reported myself in Issue #60. The problem were conflicting git ENV variables which bundler and blazing use. It has been resolved in master for a while but did not make it into a release so far. I just released 0.2.11 with the fix in it, hope this solves the problem for you as well.

Closing the issue, report back if you still get the git errors with blazing 0.2.11.

pabloalr commented 12 years ago

Greetings!

Just got this issue with git after upgrading again to 0.2.11 after recreating hooks with 0.2.10.

effkay commented 12 years ago

@pabloalr that's to be expected, as the generated hook changes from 0.2.10 to 0.2.11. From 0.2.11 on, the conflicting ENV variables are unset by the hook. So only a hook generated by 0.2.11 will fix this issue.