bundle check always fails (and why do we even need this extra step?)

[ayoubkhobalatte]

What does this check in bundler.cap (like 31) do

unless test(:bundle, :check, *options)

This is always returns false for me and therefore bundler:install gets skipped.

[mattbrictson]

Can you try running the command via SSH? For example, I see:

$ bundle check
The Gemfile's dependencies are satisfied

The documentation says:

check searches the local machine for each of the gems requested in the Gemfile. If all gems are found, Bundler prints a success message and exits with a status of 0. If not, the first missing gem is listed and Bundler exits status 1.

In other words, if bundle check succeeds, that means no gems need to be installed. Therefore bundle install is unnecessary and can be skipped.

Are you seeing a situation where bundle check succeeds even though gems are missing?

[ayoubkhobalatte]

My dependencies didn't change so it makes sense now. I was under the impression bundle would run on all deploys, regardless of wether the Gemfile has changed or not.

So this is not a bug, just my bad. But It would be nice to print All gems are statified intsead of nothing, I think. Closing this.

[LoveEachDay]

Why not options << "--without #{fetch(:bundle_without)}" if fetch(:bundle_without) set before bundle check is executed?

[mattbrictson]

bundle check does not accept the --without option.

[LoveEachDay]

So bundle check will always fail in production, because bundle install without the development and test group.

[mattbrictson]

Good question.

bundle check honors the settings stored in .bundle/config from previous bundle install executions. So yes, it will properly ignore development and test groups and not fail in production.

I just verified this in a production environment that was deployed with capistrano-bundler.

$ bundle check
The Gemfile's dependencies are satisfied
$ cat .bundle/config 
---
BUNDLE_PATH: "/home/deployer/apps/[redacted]/shared/bundle"
BUNDLE_DISABLE_SHARED_GEMS: "true"
BUNDLE_RETRY: "3"
BUNDLE_FROZEN: "1"
BUNDLE_WITHOUT: "development:test"

The check command succeeds, even though gems in the test group are not installed.

$ bundle show capybara
Could not find gem 'capybara'.
Did you mean capybara?

So it seems to work as intended.

[mattbrictson]

Of course, this probably only works if you are symlinking .bundle/config using Capistrano's :linked_dirs (as I do for all my deployments). Perhaps this should be mentioned in the README?

I am also skeptical that bundle check actually saves any time. After all, bundle install will exit immediately if there are no gems to install, right? It does not seem necessary, but perhaps I am missing something.

I'll reopen this issue since it seems there is more to discuss here. I'm interested in any further thoughts or suggestions you have on this topic.

[fbluemel]

For me, bundle install would waste time on every deploy and I didn't understand why. Without this issue, I still wouldn't have .bundle in the :linked_dirs so yes, I think this really should be in the README.

In this particular deployment the bundle install takes 4 seconds to realize that nothing needs to be installed; bundle check knows that instantly. So bundle check does indeed save time. (In this case deployment time is <10s, so an extra 4 weren't exactly nothing.)

[mattbrictson]

Thanks for the feedback and real-world data, @fbluemel. I agree we need to update the README. I just opened #96 to track this. Do you have time to contribute a PR?

[spajic]

@mattbrictson Hello!
I just encountered this issue and solved it with alternative way.

I do

execute :bundle, :config, "--local without development:test"
execute :bundle, :config, "--local path /my/shared/gems/path"

before attempt to bundle check.

So, bundle check, bundle install, bundle exec all work with the same without and path options.

I think it is slightly more convenient than symlink of .bundle/config because it will work out of the box.

What do you think about this approach?

I have made a PR for that: #97

[vassilevsky]

I opened #99 and only after that found this issue.

bundle check absolutely fails for me each time. bundle install ran every time. I got irritated and made a fix in #99 🙃

[vassilevsky]

bundle install will exit immediately if there are no gems to install, right?

Wrong 🙃 It will load metadata from rubygems and our private gem host (based on geminabox) for about 22 seconds 😢

[vassilevsky]

That was a bad fix so I closed it.

[GeminPatel]

I faced the same issue and after lots and lots of problems I was able to arrive at the same conclusion.

Also I was trying to use per-release binstub. The problem is that I have no way of excluding the bundle check. If there are no changes to the gems, I will not be able to create a per-release binstub. Maybe this can be a reason to either exclude or give an option for bundle check?

[mattbrictson]

@GeminPatel I'd consider a :bundle_check_before_install option that defaults to true and skips the check step if explicitly set to false. Would you be willing to submit a PR for something along those lines?

[chadwilken]

I've also hit the binstub issue. When it generates the binstubs it uses the directory for the pending release as the fallback directory for the Gemfile. It took me a bit to figure out what was going on after a hard-restart of puma that resulted in it failing to start. @mattbrictson if your recommendation hasn't been addressed I would be happy to open a PR.

[map7]

I get this issue when upgrading ruby on my production and staging servers.
I just upgraded to 2.5.3 and then to 2.6.1 and had the same issue on both. The bundler:install was skipped as it checked my shared bundle directory and all the gems where there, but if I login and go to my current directory for my deployed app and type 'bundle check' it tells me that none of the gems are installed because I have a new version.

[mattbrictson]

@map7 Is it because bundle check when run via Capistrano is using a different version of Ruby than bundle check when you manually log in?

[map7]

You could be right here. We use rbenv on our servers to help manage our
ruby versions maybe this is causing the problem. I'll check