Skip to content
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

Merged
merged 4 commits into from
Jan 9, 2023
Merged

Run CI with Ruby 3.2 #416

merged 4 commits into from
Jan 9, 2023

Conversation

jrochkind
Copy link
Contributor

Locally tests passed under Rails 7.0 and Ruby 3.2 with no changes to code.

@jrochkind
Copy link
Contributor Author

OK, this is weird. The failure on ruby 3.2 is that:

nokogiri-1.13.10-x86_64-linux requires ruby version < 3.2.dev, >= 2.6, which is
incompatible with the current version, ruby 3.2.0p0

It looks like there is no non-pre-release version of nokogiri out that actually works with ruby 3.2 yet? Only 1.14.0.rc1?

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....

@jrochkind
Copy link
Contributor Author

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 nokogiri-1.13.10-x86_64-linux gem, they just installed the straight nokogiri gem? 1.13.10? See eg

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?

@jrochkind
Copy link
Contributor Author

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.

- build:
name: "ruby3-2_rails7-0"
ruby_version: 3.2.0
rails_version: 7.0.3
Copy link
Member

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. 🤷

Suggested change
rails_version: 7.0.3
rails_version: 7.0.4

Copy link
Contributor Author

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.

Copy link
Contributor Author

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).

@jrochkind
Copy link
Contributor Author

Still the same failure...

nokogiri-1.13.10-x86_64-linux requires ruby version < 3.2.dev, >= 2.6, which is incompatible with the current version, ruby 3.2.0p0

OK, now the mystery is how the heck did we get a PASS on questioning_authority repo?

Here's the run:

Using nokogiri 1.13.1

https://app.circleci.com/pipelines/github/samvera/questioning_authority/765/workflows/31f3eb4f-0493-46c6-9dbd-c5acd63a69c0/jobs/8069?invite=true#step-118-67

@cjcolvar does this make any more sense to you than me?

@cjcolvar
Copy link
Member

cjcolvar commented Jan 9, 2023

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.
I didn't read through it all but it seems like this issue is relevant: sparklemotion/nokogiri#2397

@jrochkind
Copy link
Contributor Author

jrochkind commented Jan 9, 2023

Good find with that nokogiri issue!

That suggests:

until a precompiled native gem is shipped, you will have to use the ruby vanilla platform gem which will compile from source during installation. Modern bundler will do this for you automatically.

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!

@cjcolvar
Copy link
Member

cjcolvar commented Jan 9, 2023

You could try adding the cache_version property to samvera/bundle and incrementing the default value.
https://circleci.com/developer/orbs/orb/samvera/circleci-orb#commands-bundle
This might do it since it does seem like the cache is hitting on this version alone: https://app.circleci.com/pipelines/github/samvera/browse-everything/629/workflows/e44bfd6f-2be3-482c-bafd-4b18f1b1a7a6/jobs/5504?invite=true#step-108-4

@jrochkind
Copy link
Contributor Author

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 2.1.4 mentioned in there now, to 2.3.14, a more recent bundler... that risks causing more failures in some older ruby I guess! but we'll see.

@jrochkind
Copy link
Contributor Author

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 ruby3-1_rails7-0-1 job reported, that isn't mentioned in the ./circleci/config.yml?

And why is the ruby3-1_rails7-0 that is mentioned in the ./circleci/config.xml, and is required, not reporting a status?

These may be the same question maybe that job is reporting as -1, wrongly, so github thinks we don't have all required status checks? :(

I also noticed looking at ./circleci/config.yml that there are TWO place I need to add the new ruby 3.2 job, I neglected to add it to the "nightly" section, so I'll add it there too. Phew!

Copy link
Member

@cjcolvar cjcolvar left a 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.

@jrochkind
Copy link
Contributor Author

OK, now it for some reasons says all checks have passed... and the names of jobs have corrected themselves, there is no longer a ruby3-1_rails7-0-1 job.

Well THAT's weird.

OK, then merging.

@jrochkind jrochkind merged commit f03f6d4 into main Jan 9, 2023
@jrochkind jrochkind deleted the ci_ruby_3.2 branch January 9, 2023 21:16
@flavorjones
Copy link

Please see sparklemotion/nokogiri#2740 for Ruby 3.2 status updates

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants