2 Cents on Rails Update, MacOS Monterey and CircleCI

I have recently started updating Rails from 5 to 6, and it went well. The next iteration meant – it’s time to start updating dependencies.

I’ve had a dependency on libv8-node gem that jumped from 7.x to 16.10. The thing was that the neither version would compile on an older intel mac with Monterey OS, so I’ve ended up finding a hack that turns an older platform binary into the new one.

Then I got an M1 Mac, and new version compiled in a breeze, so it was time to release it.

Then CircleCI kicked in. bundle install took forever, and Re-Run with SSH revealed that poor container was trying to build the library, and 10min limit would kill it every time. Clearly, even though it’s probably possible to compile the library with each build by increasing time limit or CPU power on the CI container, it definitely isn’t a right thing to do.

Then I’ve googled for a way to persuade bundler to use binary version of a gem, and surprisingly – no one had an easy solution.

After quite some trial and error – I’ve realized that adding an explicit dependency in Gemfile would result in platform-specific (and therefore binary install eligible) Gemfile.lock entry
libv8-node (16.10.0.0-x86_64-linux) which did exactly what I’ve wanted – pull the binary rather than trigger unnecessary build.

Next run also triggered the compiler, but that was easier – I’ve had to replace gem 'sass-rails' with gem 'sassc-rails', but that was much more obvious.

Result: bundle install completed under 3min. Yay!

Related Gems (depending on libv8-node include but are not limited to:

• mini_racer
• activeadmin-searchable_select
• websocket-driver

Or perhaps – is it happening that install hangs on a random package while build is in progress – due to multi-threaded install process? I think the three above are all actually depending on a build.