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

Update button selected state to use GlButton selected prop
Use dropdown background in link popover
Use feedback design tokens for table creator

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

Changelog: added

Make sure the background migration is finalized before last required
stop (min GitLab schema version).

## 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

User will be able to store their Docker Hub credentials in the
dependency proxy for containers so that when GitLab authenticates
against Docker Hub, we will switch to an authenticated request instead
of using an unauthenticated request.

This is behind a feature flag.

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

Changelog: added
EE: true

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.

Allow the changing of timestamp when changing sort.
Also adjust the structure of storybook example to make more sense

Changelog: changed

This reverts merge request !183789

Changelog: fixed

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

Adding banner to encourage users to adopt inputs in lieu of variables

Changelog: added

Loads commit details async when details are expanded

This extraction is part of an effort to clean up our pipeline creation
integration specs.

Handle loading state in the controls section

Handle loading state in file browser on settings change

Changelog: changed

Toggling a checkbox in a work items description where there is an
opened <details> element causes the <details> element to collapse.
This fixes it in a similar way as legacy issues in
`~/issues/show/utils/update_description.js`

work_items_show_data is now used for index/show/new pages
so it is renamed to a more appropriate work_items_data name

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

Fixes reference to pull title
from design object instead of
empty title reference. Only
available behind work items feature
flags.

Move state from Vuex to a new Pinia store

Use cookies to store visibility state