'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.

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
--
--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
---
You received this message because you are subscribed to the Google Groups "Capistrano" group.
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.

Post by Donovan Bray
'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<http://stackoverflow.com/a/6693102>,
is my issue possibly related to ownership of the lock file on the server?
Is is possible that the permission structures are mismatched?

Post by Donovan Bray
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

[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.

Post by Gallagher Polyn
Firstly, thanks for your reply.

Post by Donovan Bray
Make sure you didn't .gitignore Gemfile.lock

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

Post by Donovan Bray
'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?

Post by Donovan Bray

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

--
--
* You received this message because you are subscribed to the Google Groups "Capistrano" group.
---
You received this message because you are subscribed to the Google Groups "Capistrano" group.
For more options, visit https://groups.google.com/groups/opt_out.

[Gallagher Polyn]

Post by Donovan Bray
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!

Post by Donovan Bray
Firstly, thanks for your reply.

Post by Donovan Bray
Make sure you didn't .gitignore Gemfile.lock

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

Post by Donovan Bray
'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<http://stackoverflow.com/a/6693102>,
is my issue possibly related to ownership of the lock file on the server?
Is is possible that the permission structures are mismatched?

Post by Donovan Bray
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

--
--
* You received this message because you are subscribed to the Google
Groups "Capistrano" group.
* To unsubscribe from this group, send email to
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
For more options, visit https://groups.google.com/groups/opt_out.