current_path is "releases/ls" whereas release_path is correct

[sunaku]

Hello,

I am using capistrano 2.6.0 and bundler 1.0.15 under ruby 1.9.2p180.

When I try to deploy my Rails app, Bundler's after:deploy task fails because current_path is being expanded to "releases/ls" whereas the release_path variable has the correct value:

failed: "sh -c 'cd MY_DEPLOY_DIR/releases/ls && bundle install --gemfile MY_DEPLOY_DIR/releases/ls/Gemfile --path MY_DEPLOY_DIR/shared/bundle --deployment --quiet --without development test'" on MY_HOST_NAME

I fixed this issue in Bundler itself but they rejected it, suggesting that I either monkeypatch or get this fixed in Capistrano. So here I am, please help! 🐻

Thanks for your consideration.

[leehambley]

@sunaku, please post all relevant config files, I need a minimum steps to reproduce, because this works perfectly for me… (Bundler 1.0.15, Cap 2.6.0, Ruby 1.9, Rails 3.0.9)

[leehambley]

I'm pretty sure this is user error, as I can't believe that it's been this long and nobody reported this before, and I can't reproduce it with the information here.

[software-project]

I don't think its user error. When I ls releases, I get:

/var/www/sorto/releases# ls
20110711235133

But when I deploy I bundler command is:

... bundle install --gemfile /var/www/sorto/releases/Using/Gemfile ....

I dont have Using folder or file.

[ashchan]

@leehambley, we can reproduce this issue with the following steps (well we could call this user error):

1. on local machine, set the system time to future, say one month later
2. deploy, the release path would be something like 20111225124538
3. set time back to normal and correct
4. deploy

In step four, bundler would get the current_release as 20111225124538, but the release_path would be something like 20111125125022. Bundler would install gems to the proper shared folder, but the rails app wouldn't start due to lack of .bundle folder generated.

Update: I believe @sunaku was referring current_release, not current_path. current_release is fetched via ls -x and sort, so the behavior is kind of expected.

[leehambley]

Thanks, so this isn't a bug - it's your own responsibility if your clocks are too far our of sync. Thanks for taking time to clarify steps to reproduce.