Skip to content

Fix batched_background_migrations in GitLab.com that use the old job_arguments format

This is a follow-up to the discussion in !61321 (comment 581176221)

As a summary:

The first two batched background migrations that we enqueued (for events and push_event_payloads) use the old format for the job_arguments column:

=> select id, job_class_name, table_name, column_name, job_arguments from batched_background_migrations order by id asc;
 id |            job_class_name             |        table_name        | column_name |                                job_arguments                                 
----+---------------------------------------+--------------------------+-------------+------------------------------------------------------------------------------
  1 | CopyColumnUsingBackgroundMigrationJob | events                   | id          | ["id", "id_convert_to_bigint"]
  2 | CopyColumnUsingBackgroundMigrationJob | push_event_payloads      | event_id    | ["event_id", "event_id_convert_to_bigint"]
  3 | CopyColumnUsingBackgroundMigrationJob | ci_job_artifacts         | id          | [["id", "job_id"], ["id_convert_to_bigint", "job_id_convert_to_bigint"]]
  4 | CopyColumnUsingBackgroundMigrationJob | ci_sources_pipelines     | id          | [["source_job_id"], ["source_job_id_convert_to_bigint"]]
  5 | CopyColumnUsingBackgroundMigrationJob | ci_build_needs           | id          | [["build_id"], ["build_id_convert_to_bigint"]]
  6 | CopyColumnUsingBackgroundMigrationJob | ci_builds                | id          | [["id", "stage_id"], ["id_convert_to_bigint", "stage_id_convert_to_bigint"]]
  7 | CopyColumnUsingBackgroundMigrationJob | ci_builds_runner_session | id          | [["build_id"], ["build_id_convert_to_bigint"]]
 40 | CopyColumnUsingBackgroundMigrationJob | ci_build_trace_chunks    | id          | [["build_id"], ["build_id_convert_to_bigint"]]
 73 | CopyColumnUsingBackgroundMigrationJob | ci_build_trace_sections  | build_id    | [["build_id"], ["build_id_convert_to_bigint"]]

Check that they are an array of columns instead of an array of arrays (as it was later updated to support multiple column conversions).

This is not that much of an issue and self hosted instances will have this fixed.

But as we are going to release the helper and the migrations to finalize the conversions, it would be nice not to add exceptions for those two cases.

This issue has been created to discuss and decide on how we could fix this issue:

  1. One off Production (and staging) database change --> just update the columns with an update query following the process for production changes
  2. Release a GitLab.com only migration to fix them
  3. Do nothing and make the helper aware of this case