Hey @david.wesmn this can happen sometimes when we update our 1.0 images, and it’s related to your project cache. I’ve reset the cache for you, so your next build will take a bit longer to rebuild it. You should be good to go after that.
I will try that if I have time, right now I kept bundler 1.16 but used bundle install --system instead of bundle install --deploy. But the caching is not as good then.
Thank you for reporting this and for sharing that link to the bundler issue. I’ve reproduced this and confirmed it’s a problem with bundler 1.16.0 and issue 6144.
To summarize for others, that issue affects bundle install --deployment and bundle install --path <anything>. We typically suggest --path vendor/bundle, but as long as this flag is used, bundler will follow a bad code path. This also only seems to affect certain programs and packages, ones that launch another Ruby process requiring the Bundler environment. I’ve seen this affect rake test and rails test because of the Spring loader, and cucumber.
This will let you keep using --deployment or --path vendor/bundle for caching.
As for our convenience image, I’ll create an issue with the community Ruby image to see if I can get it fixed there. We can patch this in our Ruby convenience images, but I’d prefer to keep ours as close to the community images as possible.
Thanks for updating us. I think the issue is still Bundler 1.16.0 and not Spring-specific. The suggested fix to Spring he links to has a failing test. In it, the failure messages are more dependency problems. Zak informed me that rails/rails pinned Bundler to < 1.16 because they were getting failures on their master.
You saw a regression of this behavior because we rolled back a change to our Ruby images that uninstalled Bundler 1.16.0. That version of bundler wasn’t uninstalled fully because the upstream image installs it as a default gem, making it more difficult to uninstall.
For now, can you work around this issue by uninstalling bundler 1.16.0 as in this post: