0.5.0.pre fails to install/build on Github Actions (Ruby 3.0.1) #218
Comments
Looks like a case of rubygems/rubygems#3174: Ubuntu is glibc so |
|
That almost sounds like a blocker for |
|
mini_racer 0.4.0 already depends on libv8-node (15.x) which uses the same gem platform scheme, there's not much that changes here. |
sorry, you are right of corse 🤦♂️ |
|
I find myself with the same problem on kubuntu 21.10. Is there a way to work around it (except using mini_racer 0.4.0) ? Thanks for any advice! |
|
There could be a way, but it would double the Alternatively I have a monkeypatch || patch here but it's for a bundler 1.17 / rubygems 3.0 situation: https://gist.github.com/lloeki/12dcf61324f64a2fa1e8a8b2109c1f00 It's untested against other versions, and although it only patches rubygems it may or may not break some other bundler version's assumptions about platform object comparisons. As to why it doesn't break 0.4.0: it seems to be dependent on the order in which linux and linux-musl results appear in the gem version search result list. |
|
Also, you can try updating your rubygems+bundler, if that is possible for you. |
|
Hi @lloeki, first of all thanks for your response! Unfortunately upgrading my env didn't help: Although monkeypatching could work (didn't try) I really don't want to do this on our production systems. |
Attempting to fix issue compile mini_racer v0.5.0 on GitHub Actions. See rubyjs/mini_racer#218
|
I was updating gem in RoR project and was getting same error. Removing Gemfile.lock and re-installing all gems through resolved this problem. |
|
Oookay, that worked here too, thanks @Alt3r! To be honest, I did not expect it to... I think the most interesting part is this: PLATFORMS
- ruby
+ x86_64-linuxwhich also made things like: - libv8 (8.4.255.0)
- libv8-node (15.14.0.1)
+ libv8 (8.4.255.0-x86_64-linux)
+ libv8-node (16.10.0.0-x86_64-linux)
- mini_racer (0.4.0)
- libv8-node (~> 15.14.0.0)
+ mini_racer (0.5.0)
+ libv8-node (~> 16.10.0.0)
- nokogiri (1.12.5)
- mini_portile2 (~> 2.6.1)
+ nokogiri (1.12.5-x86_64-linux)I asked a colleague to + libv8 (8.4.255.0-universal-darwin-20)
libv8 (8.4.255.0-x86_64-linux)
+ libv8-node (16.10.0.0-arm64-darwin)
libv8-node (16.10.0.0-x86_64-linux)
+ nokogiri (1.12.5-arm64-darwin)
+ racc (~> 1.4) PLATFORMS
+ arm64-darwin-20
x86_64-linuxIt seems that the PLATFORM ruby has had unhealthy implications. Not sure what's the source of all that, I don't think it a nice behaviour but now that I know it it works fine. |
|
Well, things get even more confusing from a end user perspective: I have a second project which had the same problem. Now, that I run bundle update, it simply uses the local mini_racer Not really related to to this, but in context of the original posts, it seems my system would use musl Update: JFTR; the above mentioned "Ruby-Platform" |
|
For platform bundler issues, see here rubygems/rubygems#4269 |
|
Github CI remains unwilling to use 0.5.0 on Ruby 2.6.6, even after deleting Gemfile.lock and updating as many gems as bundler could find. Reverting to 0.4.0 allows CI to start running and our Ubuntu 18 staging server to update gems, so it would seem there continues to be some incompatibility in Ruby 2.6+mini_racer 0.5.0 on Ubuntu-based platforms, which manifests as |
There's been this security-related change in recent bundler (mentioned above) where you now have to do e.g |
|
Also, see this comment I made, which should work around the issue. |
|
Thanks, for the record I was having the same issue and decided to wait until the issue settles a bit before wasting the same time as everyone else trying the same things. Now I tried again and was able to upgrade "easily" by:
|
|
I think I'm going to close this issue. Maybe we could add a FAQ/remark in the readme about this problem, but adding the "proper" platforms seems to do the trick more or less for everyone. |
|
This randomly fails in CI with the "proper" platforms set. My dev machine is an M1 macbook. |
|
Not sure this is useful, here what worked for me on Linux: |
|
This took longer than I'd like to admit; I'm no bundler expert. A combination of @jarthod and @brilnius suggestions fixed this issue for me. My company supports multiple platforms, caches gems locally in
This was all that was required. Sanity check that you're good to go with a |
rubyjs/mini_racer#218 appears to reflect the problem that we're having on Github where mini_racer doesn't work past version 0.4
rubyjs/mini_racer#218 appears to reflect the problem that we're having on Github where mini_racer doesn't work past version 0.4
|
This comment solved it for me: #218 (comment) |
|
Another workaround that may help people sometimes when you can't update rubygems/bundler, install libv8-node and mini_racer before bundle install: Since you can't use How to use that is left as an exercise for the reader. |
|
for anyone else unable to get it to work, you need to clobber any installed libv8-node files/directories, as rubygems/bundler can't remove it properly on it's own. find those files with: this is the only way to get it to work if you've attempted to bundle before adding the platform, in my experience. |
|
rails 7
|
Initially upgrading with the hopes of fixing lemurheavy/coveralls-public#1240. Upgrading how we handle the versioning according to https://andycroll.com/ruby/read-ruby-version-in-your-gemfile/. Ran into rubyjs/therubyracer#467, so I ended up resolving it by switching to mini_racer via rubyjs/mini_racer#218 (comment).
Initially upgrading with the hopes of fixing lemurheavy/coveralls-public#1240. Upgrading how we handle the versioning according to https://andycroll.com/ruby/read-ruby-version-in-your-gemfile/. Ran into rubyjs/therubyracer#467, so I ended up resolving it by switching to mini_racer via rubyjs/mini_racer#218 (comment).
Initially upgrading with the hopes of fixing lemurheavy/coveralls-public#1240. Upgrading how we handle the versioning according to https://andycroll.com/ruby/read-ruby-version-in-your-gemfile/. Ran into rubyjs/therubyracer#467, so I ended up resolving it by switching to mini_racer via rubyjs/mini_racer#218 (comment).
I'm trying to get our larger test suite running on Apple Silicon which uses
mini_racerfor more than just asset compilation. While I was giving0.5.0.prea spin it worked great locally on my Mac mini (M1, 2020), but the build failed on our GH Actions CI.Env:
2.284.0(Ubuntu 20.04.3 LTS)I think the relevant error is (find more logs below):
logs
On an unrelated:
mini_racer0.5.0.pre works otherwise fine on Docker Desktop on Apple Silicon 🎉! The forking issue still persists, but otherwise it seems to work very well./cc @lloeki
The text was updated successfully, but these errors were encountered: