The issue is to be used for tracking `db:migrate:multi-version-upgrade` stability for cases when job caused instability in master. ### Tracking broken master incidents - https://gitlab.com/gitlab-org/quality/engineering-productivity/master-broken-incidents/-/issues/5982+ - %"16.11" - Details: caught an actual migration error and root cause MR was reverted https://gitlab.com/gitlab-org/quality/engineering-productivity/master-broken-incidents/-/issues/5982#note_1872369091, however caused master-broken since `security_policy` records were generated in 16.11 PG dump while in previous dump this table didn't exist - as such `db:migrate:multi-version-upgrade` didn't fail for https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149730+ - https://gitlab.com/gitlab-org/quality/engineering-productivity/master-broken-incidents/-/issues/6238+ - Details: Caused by `postgresql` installation error in specific `bookworm` image - https://gitlab.com/gitlab-org/quality/engineering-productivity/master-broken-incidents/-/issues/6238#note_1900489347, happened once and next image didn't have this error. - https://gitlab.com/gitlab-org/release/tasks/-/issues/13031+ - Details: Backport from 16.11 was failing because it used `latest_upgrade_stop.gz` which is 17.3 on the time of writing. - Corrective action: https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/issues/3028 ### Proposed solutions 1. Disabling the job while investigation is ongoing to unblock `master` 2. If issues like this happen more often: - Adding `db:migrate:multi-version-upgrade` which would emulate upgrade from current `master` in author's MR (context https://gitlab.com/gitlab-org/quality/engineering-productivity/master-broken-incidents/-/issues/5982#note_1879130567)