Changelog: added

This change adds a new merge request approval policy action that allows
bot comment to be disabled for a given policy.

Changelog: other

Changelog: added
EE: true

Add relaxed sharding keys for feature category `groups_and_projects`.

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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

- Reverify keys when pushing new commits
- Add a flash message when a user has a GPG key is not successfully
reverified by integrations
- Prevent pushes that contain commits that were signed with GPG keys
that are not successfully reverified

Contributes to: https://gitlab.com/gitlab-org/gitlab/-/issues/442098
Changelog: changed

Allow admins of enterprise groups to disable personal access token
generation for the enterprise users. Token which are created before
disabling personal access tokens will be invalid.

Changelog: fixed
EE: true

Add relaxed sharding keys for feature category `source_code_management`.

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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

Add relaxed sharding keys for feature category `continuous_delivery`.

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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

As part of the [epic][0] to drop the
`vulnerability_occurrence_pipelines` table, we need to backfill some
new columns to migrate dependent feature to

The [backfill MR][1] is scoped to `nil` columns

```ruby
scope_to ->(relation) { relation.where(initial_pipeline_id: nil) }
```

Therefore, we are making an index to get all of the vulnerability
findings (`:id`) that have `nil` in the
column being backfilled (`:initial_pipeline_id` or
`:latest_pipeline_id`)

---

[0]:https://gitlab.com/groups/gitlab-org/-/epics/11241
[1]:https://gitlab.com/gitlab-org/gitlab/-/merge_requests/147220

[MR]:https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148470
[Related to]:https://gitlab.com/gitlab-org/gitlab/-/issues/422383
[Resolves]:https://gitlab.com/gitlab-org/gitlab/-/work_items/454236

Add relaxed sharding keys for feature category `vulnerability_management`.

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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

Add relaxed sharding keys for feature category `devops_reports`.

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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

Add relaxed 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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

Ultimately, we plan to use the index state field to filter out
orphaned indices, but there is an edge case where the associated
enabled namespace has been deleted but the state has not been updated
yet. This added filter will protect us from that scenario moving forward.

Changelog: changed
EE: true

See https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#swap-the-columns-release-n--1

Changelog: changed

Changelog: performance

There was a bug in production where the `scanner_id` of a
vulnerability finding would be updated, yet the `scanner_id` of the
related `vulnerability_read` would remain unchanged. This was an issue
as the `vulnerability_read` should always be in sync with the
`vulnerability_finding`.

The bug has already been [fixed in production][0], so now we need a
migration to fix all of the `vulnerability_reads` that were affected
by the bug.

[0]:https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148016

---

MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148807
Related to: https://gitlab.com/gitlab-org/gitlab/-/issues/454290
resolves: https://gitlab.com/gitlab-org/gitlab/-/issues/454827

Changelog: fixed
EE: true

Add and backfill project_id for deployment_approvals.

This table has 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)
configured ([view configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/deployment_approvals.yml)).

This merge request is the first step towards transforming the desired sharding key into a
[sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#defining-a-sharding-key-for-all-cell-local-tables).

This involves three changes:

- Adding a new column that will serve as the sharding key (along with the relevant index and foreign key).
- Populating the sharding key when new records are created by adding a database function and trigger.
- Scheduling a [batched background migration](https://docs.gitlab.com/ee/development/database/batched_background_migrations.html)
  to set the sharding key for existing records.

Once the background migration has completed, a second merge request will be created to finalize the background
migration and validate the not null constraint.

We have assigned a random backend engineer from ~"group::environments" to review these changes. Please review this merge
request from a ~backend perspective. The main thing we are looking to verify is that the added column and association
match the values specified by the [desired sharding key](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/deployment_approvals.yml)
configuration and that backfilling the column from this other table makes sense in the context of this feature.

When you are finished, please:

1. Trigger the [database testing pipeline](https://docs.gitlab.com/ee/development/database/database_migration_pipeline.html)
   as instructed by Danger.
1. Request a review from the ~backend maintainer and ~database reviewer suggested by Danger.

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

This merge request was generated by a once off keep implemented in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/143774

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

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

index_merge_requests_on_target_project_id_and_iid_and_state_id
seems to be unnecessary since we have a similar index called
idx_mrs_on_target_id_and_created_at_and_state_id

Changelog: other

This is the first step to convert pipeline_id related to bigint for:
- vulnerability_occurrence_pipelines.pipeline_id

See https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#initialize-the-conversion-and-start-migrating-existing-data-release-n

Changelog: added

This is the first step to convert pipeline_id related to bigint for:
- merge_trains.pipeline_id

See https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#initialize-the-conversion-and-start-migrating-existing-data-release-n

Changelog: added

- Update the timestamp of the migration that removes the
delayed_project_removal column to be greater than the
timestamp of the migration that finalises the background
migration UpdateDelayedProjectRemovalToNullForUserNamespaces.
- Skip executing FinalizeUpdateDelayedProjectRemovalToNull
migration if delayed_project_removal column does not exist.

Changelog: fixed

This is the first step to convert pipeline_id related to bigint for:
- merge_trains.pipeline_id

See https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#initialize-the-conversion-and-start-migrating-existing-data-release-n

Changelog: added

Add relaxed sharding keys for feature category `system_access`.

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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

Set the values of zoekt_settings in the application_settings from the
feature flags.

Changelog: other
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/148014
EE: true

Add relaxed sharding keys for feature category `pipeline_composition`.

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 "relaxed" sharding key has been automatically selected for these tables, referencing either `projects` or `namespaces`, or a combination of both.

The term "relaxed" is used because:

- normally, a sharding key needs to have a NOT NULL constraint on the database.
- But, "relaxed" sharding keys do not have NOT NULL constraints. However, we have verified via database-lab that these
  columns do not contain any NULL values across any rows in the table.

This means that while the NOT NULL constraint is missing, the data itself is clean, so we can always add a NOT NULL constraint after the classification of these tables are completed.

Reviwer, 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 `@manojmj` or `@tigerwnz`.

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)
using the Keeps::DetermineRelaxedShardingKey keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

This is the first step to convert pipeline_id related to bigint for:
- packages_build_infos.pipeline_id

See https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#initialize-the-conversion-and-start-migrating-existing-data-release-n

Changelog: added

This is the first step to convert pipeline_id related to bigint for:
- vulnerability_feedback.pipeline_id

See https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#initialize-the-conversion-and-start-migrating-existing-data-release-n

Changelog: added

that was added with
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/145863/

Add sharding keys for feature category `continuous_delivery`.

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 that 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 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.

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)
using the Keeps::DetermineShardingKeyFeatureCategory keep.

To provide feedback on your experience with `gitlab-housekeeper` please comment in
<https://gitlab.com/gitlab-org/gitlab/-/issues/442003>.

Changelog: other

This new column wil be used to associate merge requests
with issues table in a way that doesn't close the issues when
the MR is merged

Changelog: other

Stop using factories to create users
on some fixtures. This was causing errors
when trying to create organizations for users
with the same path making the fixtures not imdepotent.

PEP 503.

Changelog: fixed

When deleting an epic its children should not be deleted on cascade,
instead we should nullify the parent_id column

Changelog: changed

Changelog: added