Implement migration skipping when `RestrictGitlabSchema` is used
What does this MR do and why?
It does use information of database_tasks: false
to know that such connections are being shared
with main:
(a primary connection).
Such migrations even if two connections are present will be run on top of main:
connection.
This does solve migrations skipping/restrict approach since:
- If
database_tasks: true
is used, the migration will be run everywhere, but some withrestrict*
will be skipped (a message will be printed, and they will be marked viaschema_migrations
as run) - If
database_tasks: false
is used, the migration will be run only onmain:
, since nodb:migrate:ci
will exist. Such migration will not be skipped, and instead it will be run in-order on top ofmain:
This does enforce usage of gitlab:db:validate_config
in production to ensure that if migrations are skipped are actually correctly skipped.
Related:
- Add `gitlab:db:validate_config` to ensure the p... (!83118 - merged) should be merged first as it ensures correct configuration is used
-
Support `database_tasks:` for database configur... (#356009 - closed): uses
database_tasks: false
approach -
Skip migrations depending on execution context (#355014 - closed): solves the migration/skipping problem by implementing
Solution 2
- Support database migrations via `db/migrate` to... (#342378 - closed): is part of the an issue to support migrations when configured decomposed
Those MRs needs to be merged before this one can be:
-
Expose `db_database_tasks` attribute (omnibus-gitlab!5982 - merged) -
Add `databaseTasks: boolean` to `gitlab.psql.` ... (gitlab-org/charts/gitlab!2450 - merged) -
Add `gitlab:db:validate_config` to ensure the p... (!83118 - merged)
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Edited by Kamil Trzciński