-
Notifications
You must be signed in to change notification settings - Fork 21
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
Run CI with Ruby 3.2 #416
Run CI with Ruby 3.2 #416
Conversation
OK, this is weird. The failure on ruby 3.2 is that:
It looks like there is no non-pre-release version of nokogiri out that actually works with ruby 3.2 yet? Only Yet I have other CI on projects using nokogiri which definitely passed on ruby 3.2 already, very weird, I wonder what I did there.... |
OK, the difference with my other projects seems to maybe be that they, running on Github CI, did not try to install the platform-specific https://github.com/jrochkind/attr_json/actions/runs/3851088524/jobs/6561925719 Which is definitely running on ruby 3.2.0 with nokogiri 1.13.10, without getting that error. So my hypothesis is that the github CI platform is not detected as getting the platform-specifici gem, while the CircleCI one is. But the platform-specific gem won't actually work on ruby 3.2.0 yet. But even though it actually says that in it's gem metadata, bundler install is somehow not smart enough to figure that out in it's dependency resolution and get a version that works. Ughh... I could try to fight this, but maybe we just wait for nokogiri 1.14.0 final, hopefully coming soon? |
It also could be some kind of issue with the circleci orb caching of bundler/gems, which I've had trouble with before? I'm pretty confused why this is going on, why I have had no trouble using nokogiri 1.13.10 with ruby 3.2 in other contexts... and am not sure if it's true the current nokogiri release doesn't actually work with ruby 3.2 for anyone, or if it's somehow special to our environment. May have to troubleshoot further if it doesn't resolve on it's own in a few weeks. It is possible the problem is somehow special to he circleci setup/environment, in the custom samvera orb, which I'm not personally very famliar with. |
.circleci/config.yml
Outdated
- build: | ||
name: "ruby3-2_rails7-0" | ||
ruby_version: 3.2.0 | ||
rails_version: 7.0.3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about bumping the rails version to the latest? It would at least kick off another build to see if the nokogiri issue gets resolved like in QA. 🤷
rails_version: 7.0.3 | |
rails_version: 7.0.4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh nice, catch, sure, we should do that either way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If that changes it... I wonder if that means it was an issue with how we do gem caching in our circleCI orb, like maybe changing rails version broke the cache...
but if the builds never get newly released versions of gems unless rails version changes, that's actually not great for CI on several grounds (you will not be testing against actual latest dependencies).
Still the same failure...
OK, now the mystery is how the heck did we get a PASS on questioning_authority repo? Here's the run:
@cjcolvar does this make any more sense to you than me? |
I wonder if we need to run some bundler commands to set config as a circleci step to force using the platform specific or pure ruby version of nokogiri. |
Good find with that nokogiri issue! That suggests:
And that matches my experience everywhere else in other projects -- on my MacOS dev box, on my own linux deploy platforms, and on my Github Actions CI. On all of those, bundler is automatically making it work out, although at cost of compiling from source. But not here. (I actually did notice that happening on my dev Mac, and wondered, huh, normally nokogiri doesn't compile from source anymore, I wonder what happened?) The question is why it's not happening in our CircleCI deploy. :(. And why over in questioning_authority it initially wasn't happening, then magically started happening, with no apparent changes. My first hypothesis would still be that it's something in our custom samvera "orb" related to cacheing, since I've had mysterious problems there before. Do you know if there's a way to get it to refresh/erase whatever cache it's got? I guess either we troubleshoot it, or we try to wait it out for nokogiri 1.14! |
You could try adding the |
Thanks, useful link to orb docs! I could also try updating the bundler version, now that I see that's a value. I wish there was a way to tell it to use the latest, instead of having it fixed to a specific version mentioned in your circleci config... but I'm going to try updating from |
Updating the bundler version seems to have worked -- although I guess that may have busted the cache too! Or the older version of bundler had bugs... but I bet it busted the cache. I suspect there's a bug/misdesign in the samvera orb caching, but that's a yak I personally am not going to shave right now. Meanwhile, we have a couple other mysteries.... Why is there a And why is the These may be the same question maybe that job is reporting as I also noticed looking at |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Thanks for keeping with it and working through the issues.
OK, now it for some reasons says all checks have passed... and the names of jobs have corrected themselves, there is no longer a Well THAT's weird. OK, then merging. |
Please see sparklemotion/nokogiri#2740 for Ruby 3.2 status updates |
Locally tests passed under Rails 7.0 and Ruby 3.2 with no changes to code.