Add latest changes from gitlab-org/gitlab@15-5-stable-eev15.5.0-rc42

11 files changed, 109 insertions, 61 deletions

diff --git a/.gitlab/issue_templates/Actionable Insight - Exploration needed.md b/.gitlab/issue_templates/Actionable Insight - Exploration needed.md
index 76316fc626d..e410715909c 100644
--- a/.gitlab/issue_templates/Actionable Insight - Exploration needed.md
+++ b/.gitlab/issue_templates/Actionable Insight - Exploration needed.md
@@ -1,4 +1,4 @@
-<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Please follow the tasks outlined in this issue for best results. Learn more in the handbook here: https://about.gitlab.com/handbook/engineering/ux/ux-research-training/research-insights/#actionable-insights 
+<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Please follow the tasks outlined in this issue for best results. Learn more in the handbook here: https://about.gitlab.com/handbook/product/ux/ux-research-training/research-insights/#actionable-insights 
 
 This issue template is for an actionable insight that requires further exploration.-->
 
diff --git a/.gitlab/issue_templates/Actionable Insight - Product change.md b/.gitlab/issue_templates/Actionable Insight - Product change.md
index 6c030220636..fba467afd0e 100644
--- a/.gitlab/issue_templates/Actionable Insight - Product change.md
+++ b/.gitlab/issue_templates/Actionable Insight - Product change.md
@@ -1,4 +1,4 @@
-<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Please follow the tasks outlined in this issue for best results. Learn more in the handbook here: https://about.gitlab.com/handbook/engineering/ux/ux-research-training/research-insights/#actionable-insights 
+<!-- Actionable insights must recommend an action that needs to take place. An actionable insight both defines the insight and clearly calls out action or next step required to improve based on the result of the research observation or data. Actionable insights are tracked over time and will include follow-up. Please follow the tasks outlined in this issue for best results. Learn more in the handbook here: https://about.gitlab.com/handbook/product/ux/ux-research-training/research-insights/#actionable-insights 
 
 This issue template is for an actionable insight that requires a change in the product.-->
 
diff --git a/.gitlab/issue_templates/Bug.md b/.gitlab/issue_templates/Bug.md
index b9fed3745d1..1266ee7efe7 100644
--- a/.gitlab/issue_templates/Bug.md
+++ b/.gitlab/issue_templates/Bug.md
@@ -39,7 +39,10 @@ will also determine whether the bug is fixed in a more recent version. -->
 
 ### Output of checks
 
-<!-- If you are reporting a bug on GitLab.com, write: This bug happens on GitLab.com -->
+<!-- If you are reporting a bug on GitLab.com, uncomment below -->
+
+<!-- This bug happens on GitLab.com -->
+<!-- /label ~"reproduced on GitLab.com" -->
 
 #### Results of GitLab environment info
 
diff --git a/.gitlab/issue_templates/Deprecations.md b/.gitlab/issue_templates/Deprecations.md
index 76c66a3a891..ef6764c3621 100644
--- a/.gitlab/issue_templates/Deprecations.md
+++ b/.gitlab/issue_templates/Deprecations.md
@@ -1,4 +1,4 @@
-For guidance on the overall deprecations, removals and breaking changes workflow, please visit https://about.gitlab.com/handbook/product/gitlab-the-product/#breaking-changes-deprecations-and-removing-features
+For guidance on the overall deprecations, removals and breaking changes workflow, please visit [Breaking changes, deprecations, and removing features](https://about.gitlab.com/handbook/product/gitlab-the-product/#breaking-changes-deprecations-and-removing-features)
 
 <!-- Use this template as a starting point for deprecations. -->
 
@@ -10,6 +10,9 @@ This should contain a brief description of the feature or functionality that is
 It is recommended that you link to the documentation.
 
 The description of the deprecation should state what actions the user should take to rectify the behavior. If the deprecation is scheduled for an upcoming release, the content should remain in the deprecations documentation page until it has been completed. For example, if a deprecation is announced in 14.9 and scheduled to be completed in 15.0, the same content would be included in the documentation for 14.9, 14.10, and 15.0.
+
+**If this issue proposes a breaking change outside a major release XX.0, you need to get approval from your manager and request collaboration from Product Operations on communication. Be sure to follow the guidance [here](https://about.gitlab.com/handbook/product/gitlab-the-product/#breaking-changes-deprecations-and-removing-features.)** 
+
 -->
 
 ### Breaking Change
diff --git a/.gitlab/issue_templates/Feature Flag Roll Out.md b/.gitlab/issue_templates/Feature Flag Roll Out.md
index f3830a5cc10..a9f96a61d29 100644
--- a/.gitlab/issue_templates/Feature Flag Roll Out.md
+++ b/.gitlab/issue_templates/Feature Flag Roll Out.md
@@ -82,6 +82,7 @@ _Consider adding links to check for Sentry errors, Production logs for 5xx, 302s
 
 ### Preparation before global rollout
 
+- [ ] Set a milestone to the rollout issue to signal for enabling and removing the feature flag when it is stable.
 - [ ] Check if the feature flag change needs to be accompanied with a
   [change management issue](https://about.gitlab.com/handbook/engineering/infrastructure/change-management/#feature-flags-and-the-change-management-process).
   Cross link the issue here if it does.
@@ -167,4 +168,11 @@ You can either [create a follow-up issue for Feature Flag Cleanup](https://gitla
 /chatops run feature set <feature-flag-name> false
 ```
 
-/label ~"feature flag" ~"type::feature" ~"feature::addition"
+<!-- A feature flag can also be used for rolling out a bug fix or a maintenance work.
+In this scenario, labels must be related to it, for example; ~"type::feature", ~"type::bug" or ~"type::maintenance".
+Please use /copy_metadata to copy the labels from the issue you're rolling out. -->
+
+/label ~group::
+/label ~"feature flag"
+/assign me
+/due in 1 month
diff --git a/.gitlab/issue_templates/Feature proposal - detailed.md b/.gitlab/issue_templates/Feature proposal - detailed.md
index 48052ed49ea..9eac2ca27c5 100644
--- a/.gitlab/issue_templates/Feature proposal - detailed.md
+++ b/.gitlab/issue_templates/Feature proposal - detailed.md
@@ -37,7 +37,7 @@ Personas are described at https://about.gitlab.com/handbook/marketing/product-ma
 
 <!-- What is the single user experience workflow this problem addresses?
 For example, "The user should be able to use the UI/API/.gitlab-ci.yml with GitLab to <perform a specific task>"
-https://about.gitlab.com/handbook/engineering/ux/ux-research-training/user-story-mapping/ -->
+https://about.gitlab.com/handbook/product/ux/ux-research-training/user-story-mapping/ -->
 
 ### Proposal
 
diff --git a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
index 7ef5287aba8..6c9b8bb6d78 100644
--- a/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new Git repository type.md
@@ -51,20 +51,16 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
   bin/rails generate migration CreateCoolWidgetRegistry --database geo
   ```
 
-Geo should continue using `Gitlab::Database::Migration[1.0]` until the `gitlab_geo` schema is supported, and is for the time being exempt from being validated by `Gitlab::Database::Migration[2.0]`. This requires a developer to manually amend the migration file to change from `[2.0]` to `[1.0]` due to the migration defaults being 2.0.
-
-For more information, see the [Enable Geo migrations to use Migration[2.0]](https://gitlab.com/gitlab-org/gitlab/-/issues/363491) issue.
-
 - [ ] Replace the contents of the migration file with the following. Note that we cannot add a foreign key constraint on `cool_widget_id` because the `cool_widgets` table is in a different database. The application code must handle logic such as propagating deletions.
 
   ```ruby
   # frozen_string_literal: true
 
-  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[1.0]
+  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.0]
     disable_ddl_transaction!
 
     def up
-      ApplicationRecord.transaction do
+      Geo::TrackingBase.transaction do
         create_table :cool_widget_registry, id: :bigserial, force: :cascade do |t|
           t.bigint :cool_widget_id, null: false
           t.datetime_with_timezone :created_at, null: false
@@ -105,6 +101,13 @@ For more information, see the [Enable Geo migrations to use Migration[2.0]](http
   ```
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
+
+- [ ] Add the new table to the GitLab Schema defined in [`ee/lib/ee/gitlab/database/gitlab_schemas.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/database/gitlab_schemas.yml).
+
+   ```yaml
+   cool_widget_registry: :gitlab_geo
+   ```
+
 - [ ] Run Geo tracking database migrations:
 
   ```shell
@@ -141,7 +144,7 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
         t.datetime_with_timezone :verification_started_at
         t.datetime_with_timezone :verification_retry_at
         t.datetime_with_timezone :verified_at
-        t.references :cool_widget, primary_key: true, null: false, foreign_key: { on_delete: :cascade }
+        t.references :cool_widget, primary_key: true, default: nil, index: false, foreign_key: { on_delete: :cascade }
         t.integer :verification_state, default: 0, limit: 2, null: false
         t.integer :verification_retry_count, limit: 2
         t.binary :verification_checksum, using: 'verification_checksum::bytea'
@@ -162,6 +165,12 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
 
+- [ ] Add the new table to the GitLab Schema defined in [`lib/gitlab/database/gitlab_schemas.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/database/gitlab_schemas.yml) with the databases they need to be added to.
+
+   ```yaml
+   cool_widget_states: :gitlab_main
+   ```
+
 - [ ] Run database migrations:
 
   ```shell
@@ -260,7 +269,6 @@ That's all of the required database changes.
     def pool_repository
       nil
     end
-    ...
 
     def cool_widget_state
       super || build_cool_widget_state
@@ -380,14 +388,16 @@ That's all of the required database changes.
   ```ruby
   # frozen_string_literal: true
 
-  class Geo::CoolWidgetRegistry < Geo::BaseRegistry
-    include ::Geo::ReplicableRegistry
-    include ::Geo::VerifiableRegistry
+  module Geo
+    class CoolWidgetRegistry < Geo::BaseRegistry
+      include ::Geo::ReplicableRegistry
+      include ::Geo::VerifiableRegistry
 
-    MODEL_CLASS = ::CoolWidget
-    MODEL_FOREIGN_KEY = :cool_widget_id
+      MODEL_CLASS = ::CoolWidget
+      MODEL_FOREIGN_KEY = :cool_widget_id
 
-    belongs_to :cool_widget, class_name: 'CoolWidget'
+      belongs_to :cool_widget, class_name: 'CoolWidget'
+    end
   end
   ```
 
@@ -454,13 +464,13 @@ That's all of the required database changes.
 - [ ] Add the following to `spec/factories/cool_widgets.rb`:
 
   ```ruby
-  trait(:verification_succeeded) do
+  trait :verification_succeeded do
     with_file
     verification_checksum { 'abc' }
     verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
   end
 
-  trait(:verification_failed) do
+  trait :verification_failed do
     with_file
     verification_failure { 'Could not calculate the checksum' }
     verification_state { CoolWidget.verification_state_value(:verification_failed) }
@@ -498,11 +508,11 @@ That's all of the required database changes.
     factory :geo_cool_widget_state, class: 'Geo::CoolWidgetState' do
       cool_widget
 
-      trait(:checksummed) do
+      trait :checksummed do
         verification_checksum { 'abc' }
       end
 
-      trait(:checksum_failure) do
+      trait :checksum_failure do
         verification_failure { 'Could not calculate the checksum' }
       end
     end
@@ -552,8 +562,9 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
   field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
         null: true,
         resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node',
-        feature_flag: :geo_cool_widget_replication
+        description: 'Find Cool Widget registries on this Geo node. '\
+                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
+        alpha: { milestone: '15.5' } # Update the milestone
   ```
 
 - [ ] Add the new `cool_widget_registries` field name to the `expected_fields` array in `ee/spec/graphql/types/geo/geo_node_type_spec.rb`.
@@ -618,13 +629,15 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
     module Geo
       # rubocop:disable Graphql/AuthorizeTypes because it is included
       class CoolWidgetRegistryType < BaseObject
+        graphql_name 'CoolWidgetRegistry'
+
         include ::Types::Geo::RegistryType
 
-        graphql_name 'CoolWidgetRegistry'
         description 'Represents the Geo replication and verification state of a cool_widget'
 
         field :cool_widget_id, GraphQL::Types::ID, null: false, description: 'ID of the Cool Widget.'
       end
+      # rubocop:enable Graphql/AuthorizeTypes
     end
   end
   ```
@@ -708,14 +721,15 @@ As illustrated by the above two examples, batch destroy logic cannot be handled
   - [ ] Add a step to `Test replication and verification of Cool Widgets on a non-GDK-deployment. For example, using GitLab Environment Toolkit`.
   - [ ] Add a step to `Ping the Geo PM and EM to coordinate testing`. For example, you might add steps to generate Cool Widgets, and then a Geo engineer may take it from there.
 - [ ] In `ee/config/feature_flags/development/geo_cool_widget_replication.yml`, set `default_enabled: true`
-- [ ] In `ee/app/graphql/types/geo/geo_node_type.rb`, remove the `feature_flag` option for the released type:
+- [ ] In `ee/app/graphql/types/geo/geo_node_type.rb`, remove the `alpha` option for the released type:
 
   ```ruby
   field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
         null: true,
         resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node',
-        feature_flag: :geo_cool_widget_replication # REMOVE THIS LINE
+        description: 'Find Cool Widget registries on this Geo node. '\
+                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
+        alpha: { milestone: '15.5' } # Update the milestone
   ```
 
 - [ ] Run `bundle exec rake gitlab:graphql:compile_docs` after the step above to regenerate the GraphQL docs.
diff --git a/.gitlab/issue_templates/Geo Replicate a new blob type.md b/.gitlab/issue_templates/Geo Replicate a new blob type.md
index 17a4dd4bc3e..76fe1772921 100644
--- a/.gitlab/issue_templates/Geo Replicate a new blob type.md
+++ b/.gitlab/issue_templates/Geo Replicate a new blob type.md
@@ -53,20 +53,16 @@ Geo secondary sites have a [Geo tracking database](https://gitlab.com/gitlab-org
   bin/rails generate migration CreateCoolWidgetRegistry --database geo
   ```
 
-Geo should continue using `Gitlab::Database::Migration[1.0]` until the `gitlab_geo` schema is supported, and is for the time being exempt from being validated by `Gitlab::Database::Migration[2.0]`. This requires a developer to manually amend the migration file to change from `[2.0]` to `[1.0]` due to the migration defaults being 2.0.
-
-For more information, see the [Enable Geo migrations to use Migration[2.0]](https://gitlab.com/gitlab-org/gitlab/-/issues/363491) issue.
-
 - [ ] Replace the contents of the migration file with the following. Note that we cannot add a foreign key constraint on `cool_widget_id` because the `cool_widgets` table is in a different database. The application code must handle logic such as propagating deletions.
 
   ```ruby
   # frozen_string_literal: true
 
-  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[1.0]
+  class CreateCoolWidgetRegistry < Gitlab::Database::Migration[2.0]
     disable_ddl_transaction!
 
     def up
-      ApplicationRecord.transaction do
+      Geo::TrackingBase.transaction do
         create_table :cool_widget_registry, id: :bigserial, force: :cascade do |t|
           t.bigint :cool_widget_id, null: false
           t.datetime_with_timezone :created_at, null: false
@@ -105,6 +101,13 @@ For more information, see the [Enable Geo migrations to use Migration[2.0]](http
   ```
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
+
+- [ ] Add the new table to the GitLab Schema defined in [`ee/lib/ee/gitlab/database/gitlab_schemas.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/ee/gitlab/database/gitlab_schemas.yml).
+
+   ```yaml
+   cool_widget_registry: :gitlab_geo
+   ```
+
 - [ ] Run Geo tracking database migrations:
 
   ```shell
@@ -143,7 +146,7 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
         t.datetime_with_timezone :verification_started_at
         t.datetime_with_timezone :verification_retry_at
         t.datetime_with_timezone :verified_at
-        t.references :cool_widget, primary_key: true, null: false, foreign_key: { on_delete: :cascade }
+        t.references :cool_widget, primary_key: true, default: nil, index: false, foreign_key: { on_delete: :cascade }
         t.integer :verification_state, default: 0, limit: 2, null: false
         t.integer :verification_retry_count, limit: 2
         t.binary :verification_checksum, using: 'verification_checksum::bytea'
@@ -164,6 +167,12 @@ The Geo primary site needs to checksum every replicable so secondaries can verif
 
 - [ ] If deviating from the above example, then be sure to order columns according to [our guidelines](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/development/ordering_table_columns.md).
 
+- [ ] Add the new table to the GitLab Schema defined in [`lib/gitlab/database/gitlab_schemas.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/database/gitlab_schemas.yml) with the databases they need to be added to.
+
+   ```yaml
+   cool_widget_states: :gitlab_main
+   ```
+
 - [ ] Run database migrations:
 
   ```shell
@@ -238,7 +247,8 @@ That's all of the required database changes.
         # we want to know which records to replicate. This is not easy to automate
         # because for example:
         #
-        # * The "selective sync" feature allows admins to choose which namespaces #   to replicate, per secondary site. Most Models are scoped to a
+        # * The "selective sync" feature allows admins to choose which namespaces
+        #   to replicate, per secondary site. Most Models are scoped to a
         #   namespace, but the nature of the relationship to a namespace varies
         #   between Models.
         # * The "selective sync" feature allows admins to choose which shards to
@@ -256,7 +266,6 @@ That's all of the required database changes.
         CoolWidgetState
       end
     end
-    ...
 
     def cool_widget_state
       super || build_cool_widget_state
@@ -308,7 +317,7 @@ That's all of the required database changes.
   end
   ```
 
-- [ ] Generate the feature flag definition fileы by running the feature flag commands and following the command prompts:
+- [ ] Generate the feature flag definition file by running the feature flag commands and following the command prompts:
 
   ```shell
   bin/feature-flag --ee geo_cool_widget_replication --type development --group 'group::geo'
@@ -346,14 +355,16 @@ That's all of the required database changes.
   ```ruby
   # frozen_string_literal: true
 
-  class Geo::CoolWidgetRegistry < Geo::BaseRegistry
-    include ::Geo::ReplicableRegistry
-    include ::Geo::VerifiableRegistry
+  module Geo
+    class CoolWidgetRegistry < Geo::BaseRegistry
+      include ::Geo::ReplicableRegistry
+      include ::Geo::VerifiableRegistry
 
-    MODEL_CLASS = ::CoolWidget
-    MODEL_FOREIGN_KEY = :cool_widget_id
+      MODEL_CLASS = ::CoolWidget
+      MODEL_FOREIGN_KEY = :cool_widget_id
 
-    belongs_to :cool_widget, class_name: 'CoolWidget'
+      belongs_to :cool_widget, class_name: 'CoolWidget'
+    end
   end
   ```
 
@@ -420,13 +431,13 @@ That's all of the required database changes.
 - [ ] Add the following to `spec/factories/cool_widgets.rb`:
 
   ```ruby
-  trait(:verification_succeeded) do
+  trait :verification_succeeded do
     with_file
     verification_checksum { 'abc' }
     verification_state { CoolWidget.verification_state_value(:verification_succeeded) }
   end
 
-  trait(:verification_failed) do
+  trait :verification_failed do
     with_file
     verification_failure { 'Could not calculate the checksum' }
     verification_state { CoolWidget.verification_state_value(:verification_failed) }
@@ -438,6 +449,8 @@ That's all of the required database changes.
 - [ ] Following [the example of Merge Request Diffs](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63309) add a `Geo::CoolWidgetState` model in `ee/app/models/ee/geo/cool_widget_state.rb`:
 
   ``` ruby
+  # frozen_string_literal: true
+
   module Geo
     class CoolWidgetState < ApplicationRecord
       include EachBatch
@@ -462,11 +475,11 @@ That's all of the required database changes.
     factory :geo_cool_widget_state, class: 'Geo::CoolWidgetState' do
       cool_widget
 
-      trait(:checksummed) do
+      trait :checksummed do
         verification_checksum { 'abc' }
       end
 
-      trait(:checksum_failure) do
+      trait :checksum_failure do
         verification_failure { 'Could not calculate the checksum' }
       end
     end
@@ -516,8 +529,9 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
   field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
         null: true,
         resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node',
-        feature_flag: :geo_cool_widget_replication
+        description: 'Find Cool Widget registries on this Geo node. '\
+                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
+        alpha: { milestone: '15.5' } # Update the milestone
   ```
 
 - [ ] Add the new `cool_widget_registries` field name to the `expected_fields` array in `ee/spec/graphql/types/geo/geo_node_type_spec.rb`.
@@ -582,13 +596,15 @@ The GraphQL API is used by `Admin > Geo > Replication Details` views, and is dir
     module Geo
       # rubocop:disable Graphql/AuthorizeTypes because it is included
       class CoolWidgetRegistryType < BaseObject
+        graphql_name 'CoolWidgetRegistry'
+
         include ::Types::Geo::RegistryType
 
-        graphql_name 'CoolWidgetRegistry'
         description 'Represents the Geo replication and verification state of a cool_widget'
 
-        field :cool_widget_id, GraphQL::ID_TYPE, null: false, description: 'ID of the Cool Widget'
+        field :cool_widget_id, GraphQL::Types::ID, null: false, description: 'ID of the Cool Widget.'
       end
+      # rubocop:enable Graphql/AuthorizeTypes
     end
   end
   ```
@@ -673,14 +689,15 @@ As illustrated by the above two examples, batch destroy logic cannot be handled
   - [ ] Add a step to `Test replication and verification of Cool Widgets on a non-GDK-deployment. For example, using GitLab Environment Toolkit`.
   - [ ] Add a step to `Ping the Geo PM and EM to coordinate testing`. For example, you might add steps to generate Cool Widgets, and then a Geo engineer may take it from there.
 - [ ] In `ee/config/feature_flags/development/geo_cool_widget_replication.yml`, set `default_enabled: true`
-- [ ] In `ee/app/graphql/types/geo/geo_node_type.rb`, remove the `feature_flag` option for the released type:
+- [ ] In `ee/app/graphql/types/geo/geo_node_type.rb`, remove the `alpha` option for the released type:
 
   ```ruby
   field :cool_widget_registries, ::Types::Geo::CoolWidgetRegistryType.connection_type,
         null: true,
         resolver: ::Resolvers::Geo::CoolWidgetRegistriesResolver,
-        description: 'Find Cool Widget registries on this Geo node',
-        feature_flag: :geo_cool_widget_replication # REMOVE THIS LINE
+        description: 'Find Cool Widget registries on this Geo node. '\
+                     'Ignored if `geo_cool_widget_replication` feature flag is disabled.',
+        alpha: { milestone: '15.5' } # Update the milestone
   ```
 
 - [ ] Run `bundle exec rake gitlab:graphql:compile_docs` after the step above to regenerate the GraphQL docs.
diff --git a/.gitlab/issue_templates/QA Failure.md b/.gitlab/issue_templates/QA Failure.md
index 3171923d8c5..bcfe7c42e90 100644
--- a/.gitlab/issue_templates/QA Failure.md
+++ b/.gitlab/issue_templates/QA Failure.md
@@ -56,6 +56,9 @@ If you include multiple screenshots it can be helpful to hide all but the first
 <!-- Base labels. -->
 /label ~Quality ~QA ~test
 
+<!-- Work classification type label, please apply ignore type label until the investigation is complete and an [issue type](https://about.gitlab.com/handbook/engineering/metrics/#work-type-classification) is determined.-->
+/label ~"type::ignore" 
+
 <!-- Test failure type label, please use just one.-->
 /label ~"failure::broken-test" ~"failure::flaky-test" ~"failure::stale-test" ~"failure::test-environment" ~"failure::investigating" ~"failure::new"
 
diff --git a/.gitlab/issue_templates/Solution Validation.md b/.gitlab/issue_templates/Solution Validation.md
index 27f97d8dd12..e7ab7fe820f 100644
--- a/.gitlab/issue_templates/Solution Validation.md
+++ b/.gitlab/issue_templates/Solution Validation.md
@@ -26,7 +26,7 @@
 
 <!-- #### TODO Checklist
  Consider adding a checklist in order to keep track of what stage the research is up to. Some possible checklist templates are here:
- https://about.gitlab.com/handbook/engineering/ux/ux-research-training/templates-resources-for-research-studies/#checklists
+ https://about.gitlab.com/handbook/product/ux/ux-research-training/templates-resources-for-research-studies/#checklists
  -->
 
 /label ~"workflow::solution validation"
\ No newline at end of file
diff --git a/.gitlab/issue_templates/UX Theme.md b/.gitlab/issue_templates/UX Theme.md
index 043cb705352..2ba60523e20 100644
--- a/.gitlab/issue_templates/UX Theme.md
+++ b/.gitlab/issue_templates/UX Theme.md
@@ -1,6 +1,6 @@
 <!-- A majority of the work designers do will be on themes in the (Now) Next 1-3 milestone column. These themes are comprised of high-confidence outcomes and validated needs. The UX theme issue is where collaboration should occur, including plans and discussion on subthemes, research, and design feedback. Related issues for design exploration and solution validation should stem from the theme issue. 
 
-One of the advantages of working with UX themes is that it allows us to think and design holistically by designing the theme as a whole as opposed to a single issue at a time trying to piece them together as you go. For more details please refer to this section of the handbook when creating UX Themes: https://about.gitlab.com/handbook/engineering/ux/product-design/ux-roadmaps/#theme-structure -->
+One of the advantages of working with UX themes is that it allows us to think and design holistically by designing the theme as a whole as opposed to a single issue at a time trying to piece them together as you go. For more details please refer to this section of the handbook when creating UX Themes: https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#theme-structure -->
 
 ### UX Theme 
 <!-- A theme is written as a statement that combines the beneficiary, their need, and the expected outcome when the work is delivered. Well-defined statements are concise without sacrificing the substance of the theme so that anyone can understand it at a glance. (For instance; Reduce the effort for security teams to identify and escalate business-critical risks) 
@@ -37,7 +37,7 @@ One of the advantages of working with UX themes is that it allows us to think an
 
 
 #### Confidence
-<!-- How well do we understand the user's problem and their need? Refer to https://about.gitlab.com/handbook/engineering/ux/product-design/ux-roadmaps/#confidence to assess confidence -->
+<!-- How well do we understand the user's problem and their need? Refer to https://about.gitlab.com/handbook/product/ux/product-design/ux-roadmaps/#confidence to assess confidence -->
 
 
 | Confidence | Research | 
@@ -55,7 +55,7 @@ Note: This is not a backlog. If the subthemes can not be delivered in the theme
 
 Note: if feature issues already exist then you can add them to this table. Keep in mind that subthemes require validation if they are assumptive 
 
-Refer to https://about.gitlab.com/handbook/engineering/ux/product-designer/#ux-issue-weights for calculating UX weights.
+Refer to https://about.gitlab.com/handbook/product/ux/product-designer/#ux-issue-weights for calculating UX weights.
 --> 
 
 | Issue | UX Weight |