Decouple MR pipelines from RUBY_VERSION_NEXT bumps

What does this MR do and why?

On 2026-08-26, bumping RUBY_VERSION_NEXT to 3.4.10 put every merge request pipeline on Ruby 3.4 at once, and we reverted it the same day. Seven workflow rules read RUBY_VERSION_NEXT when they should read the default version.

This MR makes four changes:

  • The seven merge request rules now use the default Ruby version. A RUBY_VERSION_NEXT bump only changes the scheduled next-Ruby pipelines and a few small version-matrix jobs.
  • A new label, pipeline:run-with-ruby-next, runs a single MR on the next Ruby version, like pipeline:run-with-rails-next does for Rails. Merge trains always use the default.
  • start-as-if-foss now passes the parent's Ruby version to its child pipeline. Before, the child always ran its own default.
  • Guards so this cannot quietly regress: specs assert which version each kind of MR gets (unlabelled, labelled, merge train, and the as-if-foss child), a spec fails any bump that forgets OMNIBUS_GITLAB_CACHE_EDITION, and Danger warns when an MR bumps RUBY_VERSION_NEXT without the label.

Known trade-off: with both the database label and pipeline:run-with-ruby-next, the next-Ruby rule wins and QUERY_LOG_LINE is not set.

The rails-next schedule stays on the next Ruby version for now. It should eventually move to the default, as #619382 (closed) argues. Moving it before the scheduled master build exists would leave ruby-next as the only scheduled next-Ruby coverage, so the schedule comes first.

Related: #619382 (closed)

Verification

  • All new and updated specs pass locally, and each spec guard was proven by breaking the config on purpose and watching it fail.
  • The ruby-next schedule takes the repo's values rather than overriding them. When RUBY_VERSION_NEXT was 3.4.10, its run came out as "Scheduled Ruby 3.4.10 ruby-next branch".
  • No pipeline schedule on master runs the next Ruby version. Through the hours the 3.4.10 bump sat on master, the scheduled pipelines that ran were still named "Scheduled Ruby 3.3.12 master branch". The docs claimed a default-branch next-Ruby pipeline exists, and that claim is now removed.
Edited by Richard Chong

Merge request reports

Loading
Loading