-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tebako fails to build if bundler version is different than in Gemfile.lock #164
Comments
I'm no longer sure if it's just the bundler switching. I'm running into the same building issue again, even though I'm modifying Here's the log for one of the runs but the issue exists on both linux and Mac:
Unfortunately I'm on vacation for the next two weeks so I won't be able to debug this and try to narrow down the problem. |
I was trying to fix the issue but unfortunately my knowledge of how bundler version switching works was not enough. The problem happened because when we run Ultimately I've managed to workaround the issue with: export BUNDLER_VERSION=$(bundle --version|cut -d' ' -f 3) This forces bundler to use the current version instead of the one from Gemfile.lock so it's not ideal. |
(1) is not correct if Ruby version is specified in Gemfile and it is normally specified for RoR projects So we need
|
Discovered while debugging #161
It seems to be a problem with the binary gems (
ffi
,jaro_winkler
) and the Ruby interpreter used betweenbundle install
andbundle exec gem build
changing if your project has both gemspec and Gemfile. I did not check for other scenarios.I've modified the
tebako
code to runbundle env
before and after the install process and ran everything in verbose mode. This was the result:The env before the install:
The env after install:
The bundler version change happened because my
Gemfile.lock
was bundled with 2.4.18 instead of 2.4.22. It seems that automatic bundler version switch messes up with which Ruby interpreter will be picked which in turn somehow breaks the binary gems resolution. In this case the ruby version is the same but in different path, on CI it was completely different (3.3.0, likely either system or rbenv default one)Manually modifying
Gemfile.lock
and swapping the bundler version fixed the problem and allowed me to proceed further.The text was updated successfully, but these errors were encountered: