Changelog: other

- merge_requests.head_pipeline_id_convert_to_bigint
- merge_request_metrics.pipeline_id_convert_to_bigint
- merge_trains.pipeline_id_convert_to_bigint
- vulnerability_feedback.pipeline_id_convert_to_bigint
- vulnerability_occurrence_pipelines.pipeline_id_convert_to_bigint

Changelog: changed

## What does this MR do and why?

Add and backfill project_id for evidences.

This table has a
[desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#define-a-desired_sharding_key-to-automatically-backfill-a-sharding_key)
configured ([view configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/evidences.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.

## How to verify

We have assigned a random backend engineer from ~"group::compliance" 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/evidences.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

- include concerns that can be reused
- implement methods and classes for Discussion
- add specs
- add adding type to notes migration

Changelog: other

New column to store HMAC secret and
initialization vector. These secrets
will be used for authentication of
external status checks

Changelog: added
EE: true

Replaces the non-partitioned FK with a partitioned one
Changelog: other

Add a migration to add maximum_storage_bytes bigint columns
to zoekt_indices table.

Changelog: other
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/159382

pm_affected_packages.

Changelog: added

Replaces the non-partitioned FK with a partitioned one
Changelog: other

Replaces the non-partitioned FK with a partitioned one
Changelog: other

Changelog: other

Add and backfill group_id for approval_group_rules_protected_branches.

This table has a
[desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#define-a-desired_sharding_key-to-automatically-backfill-a-sharding_key)
configured ([view configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/approval_group_rules_protected_branches.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::source code" 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/approval_group_rules_protected_branches.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

Co-authored-by: Lorena Ciutacu <lciutacu@gitlab.com>

Add missing comma after
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/158372.

[skip-db-structure-check]

Changelog: added

This change adds a migration to remove NOT NULL constraint
on scan_result_policy_id for scan_result_policy_violations
as it will be replaced by approval_policy_rule_id.

Changelog: other

Replaces the non-partitioned FK with a partitioned one
Changelog: other

Changelog: other

Changelog: added
EE: true

Changelog: other

- Add MemberRoleRelation to GroupGroupLink model
- Update non_guests scope in GroupGroupLink model
- Update UserMemberRolesInGroupsPreloader to include group links

Changelog: added

Update the resolver to filter and sort results

Changelog: added

Changelog: changed
EE: true

## What does this MR do and why?

Add and backfill group_id for approval_group_rules_users.

This table has a
[desired sharding key](https://docs.gitlab.com/ee/development/database/multiple_databases.html#define-a-desired_sharding_key-to-automatically-backfill-a-sharding_key)
configured ([view configuration](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/docs/approval_group_rules_users.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.

## How to verify

We have assigned a random backend engineer from ~"group::source code" 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/approval_group_rules_users.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

This index was added to be a supporting index for a backfill
in [MR 148470][0]

This commit adds a migration to drop the index as the backfill is
complete

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

MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/158726
resolves: https://gitlab.com/gitlab-org/gitlab/-/issues/454243
Changelog: removed

MR: gitlab.com/gitlab-org/gitlab/-/merge_requests/158203

Changelog: added
EE: true

See https://docs.gitlab.com/ee/development/database/avoiding_downtime_in_migrations.html#remove-the-trigger-and-old-integer-columns-release-n--2

Changelog: removed

For each user accessing GitLab.com, the access is tracked if it is
coming from PIPL-covered countries (by checking HTTP_CF_IPCOUNTRY
request env). If the access is coming from a non PIPL-covered country
and a previous access from a PIPL-covered country was tracked for the
same user, the access count from PIPL-covered countries is reset for
the user. This tracking is only done once every 24 hours for each user.

Further, if the user is determined to be subject to PIPL, a background job is
queued to check if the user belongs to any paid namespace. This is done because
users belonging to paid namespaces are exempt from actions taken to ensure PIPL
compliance.

Changelog: removed

This MR updates the
security_policy_scheduled_scans_max_concurrency
limit for self-managed instances

Changelog: changed
EE: true

Ensure BackfillOrDropCiPipelineOnProjectId is completed and
adds non-valid not-null project_id database constraint to ci_pipelines

Changelog: changed

Virtual Registries will first support the Maven packages.
Introduce a new bounded context.
Introduce 3 tables / models required by Maven virtual registries.
Maven Registry: the registry object
Maven Registry Upstream: the joined table between Registry and Upstream
Maven Upstream: the upstream object

Changelog: added

The foreign key assumed that the pipelines were
part of a parent-child relation, but this column
is used by a different feature to mirror pipeline
statuses across projects.

Changelog: fixed

Changelog: added

Changelog: added

Add a new user type :import_user and a new
class to create a root group import_user to be used
when importing groups/projects and user contributions
have to be assigned to a generic import user

Changelog: added

This is 1 out of 3, unused indices. For details see: https://gitlab.com/gitlab-org/gitlab/-/issues/470937

Changelog: other

Changelog: other