## Context To rollout Ruby 3.3., we performed three steps: * Ruby 3.3 is tested on canary stage https://gitlab.com/gitlab-com/gl-infra/production/-/issues/20918 * GitLab.com is running on Ruby 3.3 https://gitlab.com/gitlab-com/gl-infra/production/-/work_items/21065 * Self-managed GitLab packages are running on Ruby 3.3 https://gitlab.com/gitlab-com/gl-infra/delivery/-/issues/21670 From the experience from these tasks, update the [Ruby upgrades runbook ](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/ruby-upgrades.md?ref_type=heads)if necessary, so we always have a SSoT. I prefer to have the runbook as the SSoT, so in the next Ruby upgrade, we can get the procedure from the runbook, instead of cloning the previous upgrade CRs. The problem with clone previous CRs is that it may contain old generic CR procedure. We should always create a CR fresh from the latest issue template, and then copy/paste the Ruby upgrade procedure from the runbook. ## Exit Criteria * [x] [Ruby upgrades runbook](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/ruby-upgrades.md?ref_type=heads) is updated with the latest upgrade procedure.