In GitLab 17.6, the package protection feature was made generally
available. But, this realease did not include
the deletion package protection,
see https://gitlab.com/gitlab-org/gitlab/-/issues/472655 .

The attribute `minimum_access_level_for_delete` that was introduced
in the MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179739 .

This attribute is integrated in this MR in order to prevent the deletion
of delete protected packages.

At the moment, the attribute `minimum_access_level_for_delete` cannot be
updated via UI, REST nor GraphQL API. This possibility will be added in
a future iteration.

Changelog: added

- Behind feature flag `vscode_extension_marketplace_settings`
- https://gitlab.com/gitlab-org/gitlab/-/issues/508977

Changelog: changed

## What does this MR do and why?

Add and backfill project_id for deployment_merge_requests.

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/deployment_merge_requests.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 the following changes:

- Adding a new column that will serve as the sharding key (along with the relevant asynchronous index).
- 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 add a foreign key and not null constraint.

## How to verify

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_merge_requests.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 @shubhamkrai.

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::BackfillDesiredShardingKeyLargeTable keep.

To provide feedback on your experience with `gitlab-housekeeper` please create an issue with the
label ~"GitLab Housekeeper" and consider pinging the author of this keep.

Changelog: other

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/491282

**Problem**

Currently, diff scan is applied only to git pushes via ssh/https
protocol, because there was no way to distiguishing between RPC actions
that triggered the scan.

For example, we want to skip the check for merge commit creation but
verify commits created via WebIDE.

https://gitlab.com/gitlab-org/gitlab/-/issues/423992 introduces an
option to pass additional context from Gitaly RPC endpoint to the
checker code.

**Solution**

* Provide `enable_secrets_check` to selected RPC endpoints
* Run diff scan for checks triggered by calls to these endpoints

Changelog: other

Accepting `inputs` parameter as Hash.

Signed-off-by: Siddharth Asthana <siddharthasthana31@gmail.com>

Changelog: other

This commit schedules detached partitions to be drop during weekend
if they are bigger than 150GB.

`method` is what is used in the API and controller logs. Keeping this
the same makes it easier to filter for logs properly.

Changelog: changed

- group saml users should not be in onboarding.
- remove them if they are in it.
- see https://gitlab.com/gitlab-org/gitlab/-/issues/522011

Changelog: other

EE: true
Changelog: changed

Redact named functions parameters when
logging ClickHouse sql queries.

Changelog: changed

Add unverified_author_email to the graphql verification
status field.

Update front end to consume new field to match how
templating currently handles it.

Changelog: fixed
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/181805

To display more backtrace lines in logs.

Fix Style/SendWithLiteralMethodName offenses
Remove Unnecessary disabling of GitlabSecurity/PublicSend
Fix Layout/ArgumentAlignment offenses

EE: true
Changelog: other

This MR changes TokenAuthenticatable concern's default storage strategy
from insecure to digest as a security best practice. We also intoduce an
insecure:true strategy to replace the current default and to support the
4 token types that rely on this insecure storage strategy.

Changelog: changed

This adds a new work item widget for vulnerabilities. It contains
related vulnerabilities of the work item. It's only applicable for
the work item type issue.

Changelog: added
EE: true

## What does this MR do and why?

Add and backfill project_id for approval_merge_request_rules_approved_approvers.

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_merge_request_rules_approved_approvers.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::code review" 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_merge_request_rules_approved_approvers.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 @shubhamkrai.

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 create an issue with the
label ~"GitLab Housekeeper" and consider pinging the author of this keep.

Changelog: other

Add LFK on ci_running_builds/ci_runners

Changelog: other

## What does this MR do and why?

Add and backfill project_id for approval_merge_request_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_merge_request_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 the following changes:

- Adding a new column that will serve as the sharding key (along with the relevant asynchronous index).
- 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 add a foreign key and not null constraint.

## How to verify

We have assigned a random backend engineer from ~"group::code review" 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_merge_request_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 @shubhamkrai.

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::BackfillDesiredShardingKeyLargeTable keep.

To provide feedback on your experience with `gitlab-housekeeper` please create an issue with the
label ~"GitLab Housekeeper" and consider pinging the author of this keep.

Changelog: other

The omniauth gem allows us to add custom logic to the different
phases of the OAuth flow.

Currently, the custom logic in the `before_request_phase` increments
the login counter for the user.

In order to better isolate the custom logic, this commit extracts
the logic into a separate class.

Changelog: other

The quick action was hidden behind the work_items_alpha feature flag.
This makes it available for both the legacy and new work items view
and improves spec coverage.

/add_email is still only available for work items of type issue as well as
legacy issues and legacy incidents.

When projects are imported via the Single Relation Endpoint, different
import files can be provided.

This change updates the process track to scope the tracking
per tracker_id to avoid conflicts.

Changelog: changed

Changelog: changed

Adds /milestone and /remove_milestone quick action to
epic work items.

To update a job status, the runner uses the PUT /api/v4/:jobs endpoint
with the job token in two places:

1. The PRIVATE-TOKEN header
2. The `token` parameter in the JSON body

Previously `AuthFinders` looked up the PAT and raised an unauthorized
exception because no user was found. Instead, it should continue to
see if it can authenticate the job with the `token` parameter.

This commit makes `access_token` return blank if it has the CI build
token prefix so that the exception is not raised. That way Rack Attack
can then ensure the request is authenticated with the job token.

Changelog: fixed

## What does this MR do and why?

Add and backfill project_id for packages_debian_project_component_files.

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/packages_debian_project_component_files.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::package registry" 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/packages_debian_project_component_files.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 @shubhamkrai.

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 create an issue with the
label ~"GitLab Housekeeper" and consider pinging the author of this keep.

Changelog: other

Changelog: other
EE: true

Changelog: added

As we already renamed the status widget to the
verification status widget, we can finally use
the status naming as part of the configurable
statuses initiative.

This commit renames the custom widget status
to the status widget to achieve that.

Changelog: changed

- Force cancel button on Job Details page
- Accept force parameter for /projects/:proj_id/jobs/:id/cancel

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