- Oct 14, 2024
-
-
Keeyan Nejad authored
Adds a new foreign key constraint and a multi not-null check. Deletes import_data without project_id. Changelog: performance
-
Shubham Kumar authored
Add and backfill project_id for dast_site_profiles_builds. 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/dast_site_profiles_builds.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::dynamic analysis" 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/dast_site_profiles_builds.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 !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
-
Shubham Kumar authored
## What does this MR do and why? Add and backfill project_id for dast_profiles_pipelines. 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/dast_profiles_pipelines.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::dynamic analysis" 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/dast_profiles_pipelines.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 !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
-
Niklas van Schrick authored
-
- Oct 11, 2024
-
-
Pedro Pombeiro authored
Changelog: added
-
This migration was finished at `2024-05-29 18:10:14 UTC`, you can confirm the status using our [batched background migration chatops commands](https://docs.gitlab.com/ee/development/database/batched_background_migrations.html#monitor-the-progress-and-status-of-a-batched-background-migration). To confirm it is finished you can run: ``` /chatops run batched_background_migrations status 1000553 ``` The last time this background migration was triggered was in [db/post_migrate/20240521093524_queue_backfill_boards_epic_lists_group_id.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/post_migrate/20240521093524_queue_backfill_boards_epic_lists_group_id.rb) You can read more about the process for finalizing batched background migrations in https://docs.gitlab.com/ee/development/database/batched_background_migrations.html . As part of our process we want to ensure all batched background migrations have had at least one [required stop](https://docs.gitlab.com/ee/development/database/required_stops.html) to process the migration. Therefore we can finalize any batched background migration that was added before the last required stop. This change was generated by [gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper) using the Keeps::OverdueFinalizeBackgroundMigration 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
-
Pedro Pombeiro authored
Retry after first attempt rolled back as part of a larger revert Changelog: added
-
Tianwen Chen authored
Changelog: added
-
Lorenz van Herwaarden authored
This adds a new setting called `customize_jira_issue_enabled` to the jira integration settings. It is disabled by default. Once enabled, it allows creating Jira issues for vulnerabilities via the legacy way. This redirects the user to the Jira issue form with vulnerability data pre-filled instead of a GraphQL mutation which automatically creates the issue. Changelog: added EE: true
-
Daniyal Arshad authored
- Remove model validations - Remove references in WorkspaceCreator - Remove graphql references - Remove frontend references - Remove specs and factories Changelog: changed EE: true
-
This migration was finished at `2024-08-12 03:46:04 UTC`, you can confirm the status using our [batched background migration chatops commands](https://docs.gitlab.com/ee/development/database/batched_background_migrations.html#monitor-the-progress-and-status-of-a-batched-background-migration). To confirm it is finished you can run: ``` /chatops run batched_background_migrations status 1000642 ``` The last time this background migration was triggered was in [db/post_migrate/20240722095920_queue_backfill_compliance_framework_security_policies_namespace_id.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/post_migrate/20240722095920_queue_backfill_compliance_framework_security_policies_namespace_id.rb) You can read more about the process for finalizing batched background migrations in https://docs.gitlab.com/ee/development/database/batched_background_migrations.html . As part of our process we want to ensure all batched background migrations have had at least one [required stop](https://docs.gitlab.com/ee/development/database/required_stops.html) to process the migration. Therefore we can finalize any batched background migration that was added before the last required stop. This change was generated by [gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper) using the Keeps::OverdueFinalizeBackgroundMigration 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
-
Aaron Huntsman authored
-
- Oct 10, 2024
-
-
Drew Blessing authored
Introduce new application setting to allow instance administrators to disable password authentication for users with SSO identities. Changelog: added
-
Gal Katz authored
Co-authored-by:
Gregory Havenga <11164960-ghavenga@users.noreply.gitlab.com>
-
Océane Legrand authored
Changelog: added
-
Oiza Baiye authored
This adds a column to bulk_import_entities that represents whether to import user memberships. This makes it possible for a user to opt out of importing memberships during a migration Changelog: added
-
Max Orefice authored
This commit requeues our migration to populate project_id for p_ci_pipeline_variables as the migration is stuck because of the recent ruby upgrade. Changelog: fixed
-
Heinrich Lee Yu authored
This is causing errors in production: gitlab-com/gl-infra/production#18692 so we drop this temporarily since this is still unused. Changelog: other
-
Bala Kumar authored
Changelog: other
-
- Oct 09, 2024
-
-
gdk authored
This migration was finished at `2024-05-27 11:56:09 UTC`, you can confirm the status using our [batched background migration chatops commands](https://docs.gitlab.com/ee/development/database/batched_background_migrations.html#monitor-the-progress-and-status-of-a-batched-background-migration). To confirm it is finished you can run: ``` /chatops run batched_background_migrations status 10005499 ``` The last time this background migration was triggered was in [db/post_migrate/20240521092459_queue_backfill_boards_epic_board_positions_group_id.rb](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/post_migrate/20240521092459_queue_backfill_boards_epic_board_positions_group_id.rb) You can read more about the process for finalizing batched background migrations in https://docs.gitlab.com/ee/development/database/batched_background_migrations.html . As part of our process we want to ensure all batched background migrations have had at least one [required stop](https://docs.gitlab.com/ee/development/database/required_stops.html) to process the migration. Therefore we can finalize any batched background migration that was added before the last required stop. This change was generated by [gitlab-housekeeper](https://gitlab.com/gitlab-org/gitlab/-/tree/master/gems/gitlab-housekeeper) using the Keeps::OverdueFinalizeBackgroundMigration 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
-
Michael Becker authored
In [a previous MR][0] we added the two indexes asynchronously. We need to add the indexes synchronously to complete the async index addition process outlined in the docs: - [*Create indexes asynchronously*][1] The indexes we added are copies of two existing indexes, with just the new `has_vulnerability_resolution` column appended. Therefore, we can also remove those now redundant indexes. * The redundant indexes - `index_vulnerability_reads_common_attrs_and_detection_for_groups` - `index_vulnerability_reads_common_finder_query_2` There was also a copy/paste issue with the `down` method in the async migration that I corrected. [0]:!166312 [1]:https://docs.gitlab.com/ee/development/database/adding_database_indexes.html#add-a-migration-to-create-the-index-synchronously --- Changelog: changed Resolves: #493285 Epic: &15036 MR: !167603
-
Eren Akca authored
A new configuration option called 'Allow top-level group owners to create Service Accounts' has been added to the Application Settings and Admin Area. When enabled, this setting allows top-level group owners to create and delete Service Accounts using the Groups endpoint. By default, this feature is disabled. Changelog: changed EE: true
-
Kev Kloss authored
The used migration was removed, so we need to use an existing one here.
-
Mario Celi authored
We need to backfill all issue records as we want to use this new column to filter by work item type temporarily Changelog: other
-
Rushik Subba authored
Removes the identifier_external_ids column which is no more required Changelog: removed
-
Max Orefice authored
This commit reset pick_up_at value so the records stored in ci_deleted_objects could get purged from the system. Changelog: fixed
-
Keeyan Nejad authored
This prevents placeholder contributions being remapped to the wrong user after a reassignment has already been accepted. Changelog: fixed
-
Mehmet Emin INAC authored
Changelog: fixed
-
- Oct 08, 2024
-
-
Mario Celi authored
We are going to backfill issues.correct_work_item_type_id so we need to make sure new records and updates to the issues.work_item_type_id column are also reflected on the new issues.correct_work_item_type_id column Changelog: other
-
Pedro Pombeiro authored
Changelog: added
-
Shubham Kumar authored
Add and backfill project_id for packages_composer_metadata. 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_composer_metadata.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::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_composer_metadata.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 !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
-
Shubham Kumar authored
## What does this MR do and why? Add and backfill project_id for dast_scanner_profiles_builds. 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/dast_scanner_profiles_builds.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::dynamic analysis" 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/dast_scanner_profiles_builds.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 !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
-
Krasimir Angelov authored
For GitLab.com only. Already done for self-managed with !165591. Since we started writing to this column with !164979, delete any orphaned records before creating the FK. Changelog: added
-
- Oct 07, 2024
-
-
Adrien Narinesingh authored
Async removal of the idx_sbom_components_on_name_gin index as it is no longer needed to assist with searching. Changelog: other
-
Arturo Herrero authored
Changelog: removed
-
David Fernandez authored
Make cached response upstream id and relative path unique within default records. Make sure that processing or error cached responses are not pulled by the main scenarios (get a file through the virtual registry).
-
Mehmet Emin INAC authored
Changelog: other
-
Gregory Havenga authored
Changelog: removed EE: true
-
Moaz Khalifa authored
-
Marius Bobin authored
Changelog: other
-