Update Ruby to 3.1.7#68585
Conversation
95053da to
d9af307
Compare
|
@cat5inthecradle Heads up that I ended up incorporating the switch to |
…, for consistency
snickell
left a comment
There was a problem hiding this comment.
I'm happy with switching docker tags in this PR, doing it in a separate PR would sorta just feel like make-work to me.
| rbenv install 3.1.7 && \ | ||
| eval "$(rbenv init -)" && \ | ||
| rbenv shell 3.1.0 && \ | ||
| rbenv shell 3.1.7 && \ |
There was a problem hiding this comment.
It'd be nice if we could just ADD .ruby-version and use that here, but we build this with the wrong directory context. Oh well.
There was a problem hiding this comment.
Yeah, it would in general be nice if we had some kind of single source of truth for the versions we target. I have more than once genuinely considered doing something like:
rbenv install $(curl https://raw.githubusercontent.com/code-dot-org/code-dot-org/refs/heads/staging/.ruby-version)
But fortunately I've always managed to talk myself down 😅
cat5inthecradle
left a comment
There was a problem hiding this comment.
LGTM! One PR sounds good, goodbye old too-optimistically named image 👋
Just pick up all patches to our current minor version of Ruby. Mostly doing this as part of general maintenance best practices, but we've also been eyeballing solid_queue for some future work, which requires Ruby >=3.1.6
Links
Previous update:
Testing story
Verified locally, in drone, and on an adhoc that the site builds and all tests pass.
I also verified that an existing server can successfully apply this change as an update. Specifically, I:
/var/chef/nodes/to matchsudo chef-client -o cdo-appsDeployment strategy
Given that this is a patch update, I don't anticipate anywhere near the level of fragility we usually plan for with a Ruby update. I think this one should be fine to just send through our build pipeline as a normal PR.
Follow-up work
Next in our sights: Ruby 3.2