Update Ruby to 3.2.11#71805
Conversation
…reduce flakiness when running eyes tests in drone
…eline" This reverts commit b83f33e.
…rate baseline"" This reverts commit 5723e88.
… to generate baseline""" This reverts commit 79a00ee.
…version, to generate baseline"""" This reverts commit 0ae845e.
…aging's version, to generate baseline""""" This reverts commit e2287f2.
| # actually run the tests. | ||
| - name: prepare-cacheable-build | ||
| image: codedotorg/cdo-ci:1.18 | ||
| image: codedotorg/cdo-ci:1.19 |
There was a problem hiding this comment.
should we expect a period of failing drone builds after this PR is merged, before prepare-cacheable-build completes ~60 min later, and the same again if this PR is reverted? Not necessarily a blocker for this to be merged, but could be worth sharing out to the team.
There was a problem hiding this comment.
I don't think so, no. Note that this PR passed Drone without incident
There was a problem hiding this comment.
I've gone ahead and made a backup of the drone cache, which would hopefully allow us to quickly restore passing drone builds if we need to revert this PR:
[10:15:20] Dave-M4:~/src/cdo (staging)$ AWS_PROFILE=codeorg-dev aws s3 cp s3://cdo-drone/code-dot-org/code-dot-org/staging/cache-staging-ci-build.tar.gz s3://cdo-drone/code-dot-org/code-dot-org/staging/cache-staging-ci-build-ruby-3.1.7.tar.gz
There was a problem hiding this comment.
It's possible that Drone runs which started before this PR was merged but which run the checkout step after it was merged will complain, because they will be running on the 1.18 image but will pick up the .ruby-version change when they pull from staging latest. But there's only a 3-4 minute window in which that could happen, so I don't expect more than a small handful of runs will need to be manually restarted
There was a problem hiding this comment.
Can you clarify what relevance the drone cache has here? I'm not sure I'm fully understanding your concern
There was a problem hiding this comment.
I don't think so, no. Note that this PR passed Drone without incident
Good point! probably no risk to drone cache, then. you can ignore my backup.
Links
Release announcement
Overview of major changes
Follow-up to:
eyes_seleniumto 6.12.28 #71977eyes_seleniumto 6.0 #71433Testing story
In addition to updating the Drone image, I also tested on an adhoc; both that we can successfully provision a new instance on this version of ruby, and that we can successfully apply this update to an existing instance.
Deployment notes
Developers will need to:
ruby-buildcd "$(rbenv root)/plugins/ruby-build" && git pullrbenv installfrom project rootWe should anticipate a very long deployment process for this one; a Ruby version update usually means we need to recompile all Dashboard assets from scratch, which on our servers is a multi-hour process.
As always with a major update like this one, we should also be prepared for issues which only manifest in non-test environments. Every deployment attempt should be considered speculative, and we should be prepared to revert.