'deployment flag requires a Gemfile.lock' seems to frustrate my first attempt to cap deploy:cold

[Gallagher Polyn]

Hi,

Using Capistrano v2.11.2 and Ruby 2.0.0p247 and attempting cap deploy:cold, it seems I encounter a hiccup related to some improper digestion of Gemfile.lock.

Here is a gist with my Capfile, deploy.rb and the readout resulting from the command: https://gist.github.com/gpolyn/0c7d35e52c81b8b53032

…it seems to me that the problem is encountered here...

    [localhost] sh -c 'cd /var/massiveapp/releases/20131102003502 && bundle install --gemfile /var/massiveapp/releases/20131102003502/Gemfile --path /var/massiveapp/shared/bundle --deployment --quiet --without development test'

 ** [out :: localhost] The --deployment flag requires a Gemfile.lock. Please make sure you have checked

 ** [out :: localhost] your Gemfile.lock into version control before deploying.

    command finished in 112ms

*** [deploy:update_code] rolling back

…though a (possibly unrelated) failure follows later...

failed: "sh -c 'cd /var/massiveapp/releases/20131102003502 && bundle install --gemfile /var/massiveapp/releases/20131102003502/Gemfile --path /var/massiveapp/shared/bundle --deployment --quiet --without development test'" on localhost

Thanks for any light readers can shed.

(The foregoing was undertaken as an exercise from working through "Deploying Rails" by Anthony Burns & Tom Copeland.)

Gallagher

[Donovan Bray]

It's telling you you didn't check in your Gemfile.lock to begin with. 

Make sure you didn't .gitignore Gemfile.lock

'bundle install' locally and commit the result. 

--
--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
* To post to this group, send email to capis...@googlegroups.com
* To unsubscribe from this group, send email to capistrano+...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
---
You received this message because you are subscribed to the Google Groups "Capistrano" group.
To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Gallagher Polyn]

Firstly, thanks for your reply.

Make sure you didn't .gitignore Gemfile.lock

No, I checked, and it is not included there.

 

'bundle install' locally and commit the result. 

I performed this action, and with a clean working directory the result was the same, unfortunately.

After further investigation into this and reading this little post, is my issue possibly related to ownership of the lock file on the server? Is is possible that the permission structures are mismatched?

[Donovan Bray]

Do an 'ls -lah' inside the release directory and post the results; a mismatch in owner should be clearly apparent. 

Make sure you execute the bundle install as the same user as your application runner; else chown the release directory and bundle path to your application runner after the bundle. 

Why are you using svn for a github repo?

Have you tried setting the :scm to :git, and use remote_cache strategy? It should be much faster. 

--

[Gallagher Polyn]

Why are you using svn for a github repo?

Have you tried setting the :scm to :git, and use remote_cache strategy? It should be much faster. 

Right.  Setting :scm to :git in deploy.rb fixed it.

As for why the copy_strategy, the authors write in "Deploying Rails" as follows:

"This is a convenient way to put the code onto the VM since the code export is done locally; we don't need to depend on the VM being able to connect to the remote Git repository or even having Git installed."

Maybe the same reasoning applies to remote caching -- maybe that option was added in a  Cap release subsequent to the book's publication.

Thanks a lot!