- bad sequencing of kicking this off before feature flag
  was fully enabled

Changelog: other

Changelog: changed

This commit creates the routing table for ci_job_artifacts.

Changelog: other

Add sharding keys for feature category `importers`.

These tables have been identified as
[cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).

All cell local tables require a
[sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables).

A sharding key has been automatically selected for these tables. The sharding key was chosen because it is a
`NOT NULL` column referencing either `projects` or `namespaces`.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::import and integrate" to review these changes.
Please confirm that each table should indeed be cell local, and that the selected column is an appropriate
sharding key. When you are finished, please request a review from the database maintainer suggested by Danger.

If you have any questions or concerns, reach out to @tigerwnz or @DylanGriffith.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Maxime Orefice 创作于 1 year ago ，Maxime Orefice 提交于 1 year ago

This commit enqueues a job which will create a new constraint this
weekend on ci_job_artifacts. This is a prerequisite in order to
partition this table.

Changelog: other

Direct Transfer API shows failures for the things that we could not
import. If a subrelation of a top level relation failed to import
(e.g. MR diff note) - we still show top level relation as the one
that failed to import. In reality, the top level relation is imported,
but a subrelation did not.

Update relation to include the failed to import subrelation, so it's
more obvious what exactly failed to import.

Changelog: added

in place of component_id.

EE: true
Changelog: fixed

Instance setting `math_rendering_limits_enabled` can now
be queried and set on groups as well. It is a cascading
setting, so it can be locked at any level.

Changelog: added

This is the second step to synchronously create indexes for p_ci_builds
See https://docs.gitlab.com/ee/development/database/adding_database_indexes.html#add-a-migration-to-create-the-index-synchronously

And prepare the foreign key to prevent invalid records
See https://docs.gitlab.com/ee/development/database/add_foreign_key_to_existing_column.html#prevent-invalid-records

Changelog: added

Add desired sharding keys for feature category `vulnerability_management`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::threat insights" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Add desired sharding keys for feature category `deployment_management`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::environments" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Add desired sharding keys for feature category `design_management`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::product planning" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Add desired sharding keys for feature category `compliance_management`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::compliance" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

This commit introduces a composite PK as this is necessary in
order to partition this table.

Changelog: added

Changelog: other

We have already fixed the records with null attributes in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/132480.

Changelog: other

* Can be set on a project to block code suggestions
* Later on, we will use the same setting name to block duo chat and other
  features on projects. We will also use the same setting for groups and
  subgroups.
* This will not take effect until we enable the
  `purchase_code_suggestions` feature flag because until then the group
  setting for `code_suggestions` + Ultimate license enableds access.
* After whereas after that flag is enabled, access will be determined by
  whether the user has a licensed seat. See
  https://gitlab.com/gitlab-org/gitlab/-/merge_requests/138334
* https://gitlab.com/groups/gitlab-org/-/epics/12404#note_1748487091

Add design widget to
widget_definition table and add
a design widget wrapper
graphql query for designCollection

Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/387552
Changelog: added

In https://gitlab.com/gitlab-org/gitlab/-/merge_requests/140282, we
started to ingest the "input_file_path" of SBOM components found by
Trivy. The components do not have an actual file path, so we instead
convert them into a URI of sorts that can be detected by the
"container-image:" magic string prefix. This pseudo URI contains the
entire fully qualified name of the container image, and can often be
longer than 255 characters, which started to cause a spike in SBOM
ingestion errors. To fix this, we're going to raise the max size to
1024, or twice the limit of what we would get if the container image
used the longest image name and tag supported by the GitLab container
registry.

Fix https://gitlab.com/gitlab-org/gitlab/-/issues/440705

Changelog: fixed

The SemanticVersionable concern is now supported for parsing and sorting items in the database versioned with semver.

Changelog: added
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/142228

The member guidelines will be shown on the members page for projects
or groups if the users has one of the following permissions:
- At group level: Manage group members
- At project level: Manage team members
This is helpful if you have some predefined groups that shall be
used instead of managing membership on an individual basis or if
external tooling is used to manage members.

Changelog: added

Add sharding keys for feature category `remote_development`.

These tables have been identified as
[cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).

All cell local tables require a
[sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables).

A sharding key has been automatically selected for these tables. The sharding key was chosen because it is a
`NOT NULL` column referencing either `projects` or `namespaces`.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::ide" to review these changes.
Please confirm that each table should indeed be cell local, and that the selected column is an appropriate
sharding key. When you are finished, please request a review from the database maintainer suggested by Danger.

If you have any questions or concerns, reach out to @tigerwnz or @DylanGriffith.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Adds an FK from p_ci_builds to ci_stages now that the partitiones have the foreign key

This commit also introduces synchronous validations for the FKs in the partitions, for self-managed

Changelog: other

Changelog: added

https://gitlab.com/gitlab-org/gitlab/-/issues/330098

The additional index is needed to support the filter by merge_user
in merge request views.

Changelog: other

noteable_type is already validated for prescene
in the application code and this commit
adds the corresponding DB constraint to
prevent invalid notes records.

It also contains a migration to create
an index asynchronously that will be used to
locate, backup and remove the notes records
with null noteable_type for .com.

Changelog: other

This commit backfills default protection branch
defaults in application setting

Changelog: other

Add desired sharding keys for feature category `mlops`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::mlops" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Add desired sharding keys for feature category `user_profile`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::tenant scale" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Add desired sharding keys for feature category `continuous_delivery`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::environments" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Add desired sharding keys for feature category `value_stream_management`.

These tables have been identified as a [cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).
All cell local tables require a [sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables)
or a [desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-desired_sharding_key-for-automatically-backfilling-a-sharding_key)

A desired sharding key has been automatically selected for these tables.
These keys were chosen as the desired sharding keys because the
table has a :belongs_to relationship to a table that itself has a `NOT NULL` sharding key.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::optimize" to review these changes.

Please confirm that:

- each of these tables can be classified as cell local
- the selected desired sharding key is appropriate
- the backfill configuration for the desired sharding key is correct

When you are finished, please request a review from the database maintainer suggested by Danger.
If you have any questions or concerns, reach out to @tigerwnz, @DylanGriffith or @manojmj.

If you would like to go through similar merged MRs so as to gather an understanding on this topic, you
can use [this](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name[]=automation%3Agitlab-housekeeper-authored) link.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Changelog: added
EE: true

Changelog: added
EE: true

This is the second migration to validate the foreign key synchronously

See https://docs.gitlab.com/ee/development/database/add_foreign_key_to_existing_column.html#add-a-migration-to-validate-the-fk-synchronously

Changelog: added

Add sharding keys for feature category `continuous_integration`.

These tables have been identified as
[cell local tables](https://docs.gitlab.com/ee/development/database/multiple_databases.html#guidelines-on-choosing-between-gitlab_main_cell-and-gitlab_main_clusterwide-schema).

All cell local tables require a
[sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables).

A sharding key has been automatically selected for these tables. The sharding key was chosen because it is a
`NOT NULL` column referencing either `projects` or `namespaces`.

Additionally, `gitlab_schema` has been set to `gitlab_main_cell` for any tables didn't use this schema already.
For these tables we have also added `allow_cross_joins`, `allow_cross_transactions` and
`allow_cross_foreign_keys`. These will silence any existing violations, allowing the pipeline to pass without
requiring further changes. In the future, we'll remove these `allow_...` statements and fix any violations as
they arise. You can read more about this in the [documentation for multiple databases](https://docs.gitlab.com/ee/development/database/multiple_databases.html)

We have assigned a random backend engineer from ~"group::pipeline execution" to review these changes.
Please confirm that each table should indeed be cell local, and that the selected column is an appropriate
sharding key. When you are finished, please request a review from the database maintainer suggested by Danger.

If you have any questions or concerns, reach out to @tigerwnz or @DylanGriffith.

This change was generated by
[gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper)

Changelog: other

Add migration and db docs yml file

Changelog: added
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143003