Add latest changes from gitlab-org/gitlab@master

48 files changed, 656 insertions, 417 deletions

diff --git a/app/assets/javascripts/clusters_list/components/clusters_actions.vue b/app/assets/javascripts/clusters_list/components/clusters_actions.vue
index 2675d46dd16..7b97a5af373 100644
--- a/app/assets/javascripts/clusters_list/components/clusters_actions.vue
+++ b/app/assets/javascripts/clusters_list/components/clusters_actions.vue
@@ -1,5 +1,11 @@
 <script>
-import { GlButton, GlDropdown, GlDropdownItem, GlModalDirective, GlTooltip } from '@gitlab/ui';
+import {
+  GlButton,
+  GlButtonGroup,
+  GlModalDirective,
+  GlTooltip,
+  GlDisclosureDropdown,
+} from '@gitlab/ui';
 
 import { INSTALL_AGENT_MODAL_ID, CLUSTERS_ACTIONS } from '../constants';
 
@@ -8,8 +14,8 @@ export default {
   INSTALL_AGENT_MODAL_ID,
   components: {
     GlButton,
-    GlDropdown,
-    GlDropdownItem,
+    GlButtonGroup,
+    GlDisclosureDropdown,
     GlTooltip,
   },
   directives: {
@@ -45,13 +51,17 @@ export default {
     actionItems() {
       const createCluster = {
         href: this.newClusterDocsPath,
-        title: this.$options.i18n.createCluster,
-        testid: 'create-cluster-link',
+        text: this.$options.i18n.createCluster,
+        extraAttrs: {
+          'data-testid': 'create-cluster-link',
+        },
       };
       const connectCluster = {
         href: this.addClusterPath,
-        title: this.$options.i18n.connectClusterCertificate,
-        testid: 'connect-cluster-link',
+        text: this.$options.i18n.connectClusterCertificate,
+        extraAttrs: {
+          'data-testid': 'connect-cluster-link',
+        },
       };
       const actions = [];
 
@@ -61,7 +71,6 @@ export default {
       if (this.displayClusterAgents && this.certificateBasedClustersEnabled) {
         actions.push(connectCluster);
       }
-
       return actions;
     },
   },
@@ -81,39 +90,35 @@ export default {
       :title="$options.i18n.actionsDisabledHint"
     />
 
-    <gl-button
-      v-if="!actionItems.length"
-      data-qa-selector="clusters_actions_button"
-      category="primary"
-      variant="confirm"
-      :disabled="!canAddCluster"
-      :href="defaultActionUrl"
-    >
-      {{ defaultActionText }}
-    </gl-button>
-
-    <gl-dropdown
-      v-else
+    <!--TODO: Replace button-group workaround once `split` option for new dropdowns is implemented.-->
+    <!-- See issue at https://gitlab.com/gitlab-org/gitlab-ui/-/issues/2263-->
+    <gl-button-group
       ref="actions"
-      v-gl-modal-directive="shouldTriggerModal && $options.INSTALL_AGENT_MODAL_ID"
       data-qa-selector="clusters_actions_button"
-      category="primary"
-      variant="confirm"
-      :text="defaultActionText"
-      :disabled="!canAddCluster"
-      :split-href="defaultActionUrl"
-      split
-      right
+      class="gl-w-full gl-mb-3 gl-md-w-auto gl-md-mb-0"
     >
-      <gl-dropdown-item
-        v-for="action in actionItems"
-        :key="action.title"
-        :href="action.href"
-        :data-testid="action.testid"
-        @click.stop
+      <gl-button
+        v-gl-modal-directive="shouldTriggerModal && $options.INSTALL_AGENT_MODAL_ID"
+        :href="defaultActionUrl"
+        :disabled="!canAddCluster"
+        data-testid="clusters-default-action-button"
+        category="primary"
+        variant="confirm"
       >
-        {{ action.title }}
-      </gl-dropdown-item>
-    </gl-dropdown>
+        {{ defaultActionText }}
+      </gl-button>
+      <gl-disclosure-dropdown
+        v-if="actionItems.length"
+        class="split"
+        toggle-class="gl-rounded-top-left-none! gl-rounded-bottom-left-none! gl-pl-1!"
+        category="primary"
+        variant="confirm"
+        placement="right"
+        :toggle-text="defaultActionText"
+        :items="actionItems"
+        :disabled="!canAddCluster"
+        text-sr-only
+      />
+    </gl-button-group>
   </div>
 </template>
diff --git a/app/controllers/projects/merge_requests_controller.rb b/app/controllers/projects/merge_requests_controller.rb
index 911e484393b..2172c91fc76 100644
--- a/app/controllers/projects/merge_requests_controller.rb
+++ b/app/controllers/projects/merge_requests_controller.rb
@@ -508,7 +508,12 @@ class Projects::MergeRequestsController < Projects::MergeRequests::ApplicationCo
   def merge!
     # Disable the CI check if auto_merge_strategy is specified since we have
     # to wait until CI completes to know
-    unless @merge_request.mergeable?(skip_ci_check: auto_merge_requested?)
+    skipped_checks = @merge_request.skipped_mergeable_checks(
+      auto_merge_requested: auto_merge_requested?,
+      auto_merge_strategy: params[:auto_merge_strategy]
+    )
+
+    unless @merge_request.mergeable?(**skipped_checks)
       return :failed
     end
 
diff --git a/app/models/merge_request.rb b/app/models/merge_request.rb
index 2b4d0949a92..2773569161d 100644
--- a/app/models/merge_request.rb
+++ b/app/models/merge_request.rb
@@ -1201,10 +1201,17 @@ class MergeRequest < ApplicationRecord
   end
   alias_method :wip_title, :draft_title
 
-  def mergeable?(skip_ci_check: false, skip_discussions_check: false)
+  def skipped_mergeable_checks(options = {})
+    {
+      skip_ci_check: options.fetch(:auto_merge_requested, false)
+    }
+  end
+
+  def mergeable?(skip_ci_check: false, skip_discussions_check: false, skip_approved_check: false)
     return false unless mergeable_state?(
       skip_ci_check: skip_ci_check,
-      skip_discussions_check: skip_discussions_check
+      skip_discussions_check: skip_discussions_check,
+      skip_approved_check: skip_approved_check
     )
 
     check_mergeability
@@ -1225,11 +1232,12 @@ class MergeRequest < ApplicationRecord
     ]
   end
 
-  def mergeable_state?(skip_ci_check: false, skip_discussions_check: false)
+  def mergeable_state?(skip_ci_check: false, skip_discussions_check: false, skip_approved_check: false)
     additional_checks = execute_merge_checks(
       params: {
         skip_ci_check: skip_ci_check,
-        skip_discussions_check: skip_discussions_check
+        skip_discussions_check: skip_discussions_check,
+        skip_approved_check: skip_approved_check
       }
     )
     additional_checks.success?
diff --git a/app/services/groups/update_shared_runners_service.rb b/app/services/groups/update_shared_runners_service.rb
index 35031b8de07..08b43037c4c 100644
--- a/app/services/groups/update_shared_runners_service.rb
+++ b/app/services/groups/update_shared_runners_service.rb
@@ -54,8 +54,6 @@ module Groups
         shared_runners_enabled: enabled,
         allow_descendants_override_disabled_shared_runners: false)
 
-      return if enabled && Feature.disabled?(:enable_shared_runners_for_descendants, group)
-
       group_ids = group.descendants
       unless group_ids.empty?
         Group.by_id(group_ids).update_all(
diff --git a/app/views/admin/application_settings/_usage.html.haml b/app/views/admin/application_settings/_usage.html.haml
index 05d1b602003..91cd6fe7ca0 100644
--- a/app/views/admin/application_settings/_usage.html.haml
+++ b/app/views/admin/application_settings/_usage.html.haml
@@ -7,13 +7,13 @@
 
   %fieldset
     .form-group
-      - help_link_start = link_start % { url: help_page_path('user/admin_area/settings/usage_statistics', anchor: 'version-check') }
+      - help_link_start = link_start % { url: help_page_path('administration/settings/usage_statistics', anchor: 'version-check') }
       = f.gitlab_ui_checkbox_component :version_check_enabled, _('Enable version check'),
         help_text: _("GitLab informs you if a new version is available. %{link_start}What information does GitLab Inc. collect?%{link_end}").html_safe % { link_start: help_link_start, link_end: link_end }
     .form-group
       - can_be_configured = @application_setting.usage_ping_can_be_configured?
       - service_ping_link_start = link_start % { url: help_page_path('development/service_ping/index') }
-      - deactivating_service_ping_link_start = link_start % { url: help_page_path('user/admin_area/settings/usage_statistics', anchor: 'disable-usage-statistics-with-the-configuration-file') }
+      - deactivating_service_ping_link_start = link_start % { url: help_page_path('administration/settings/usage_statistics', anchor: 'disable-usage-statistics-with-the-configuration-file') }
       - usage_ping_help_text = s_('AdminSettings|To help improve GitLab and its user experience, GitLab periodically collects usage information. %{link_start}What information is shared with GitLab Inc.?%{link_end}').html_safe % { link_start: service_ping_link_start, link_end: link_end }
       - disabled_help_text = s_('AdminSettings|Service ping is disabled in your configuration file, and cannot be enabled through this form. For more information, see the documentation on %{link_start}deactivating service ping%{link_end}.').html_safe % { link_start: deactivating_service_ping_link_start, link_end: link_end }
       = f.gitlab_ui_checkbox_component :usage_ping_enabled, s_('AdminSettings|Enable Service Ping'),
@@ -28,7 +28,7 @@
     .form-group
       - usage_ping_enabled = @application_setting.usage_ping_enabled?
       - label = s_('AdminSettings|Enable Registration Features')
-      - label_link = link_to sprite_icon('question-o'), help_page_path('user/admin_area/settings/usage_statistics', anchor: 'registration-features-program')
+      - label_link = link_to sprite_icon('question-o'), help_page_path('administration/settings/usage_statistics', anchor: 'registration-features-program')
       - help_text = usage_ping_enabled ? s_('AdminSettings|You can enable Registration Features because Service Ping is enabled. To continue using Registration Features in the future, you will also need to register with GitLab via a new cloud licensing service.') : s_('AdminSettings|To enable Registration Features, first enable Service Ping.')
       = f.gitlab_ui_checkbox_component :usage_ping_features_enabled?, '%{label} %{label_link}'.html_safe % { label: label, label_link: label_link },
         help_text: '<span id="service_ping_features_helper_text">%{help_text}</span>'.html_safe % { help_text: help_text },
diff --git a/app/views/admin/application_settings/service_usage_data.html.haml b/app/views/admin/application_settings/service_usage_data.html.haml
index 24f132b982a..634d006e736 100644
--- a/app/views/admin/application_settings/service_usage_data.html.haml
+++ b/app/views/admin/application_settings/service_usage_data.html.haml
@@ -23,7 +23,7 @@
       title: _('Service Ping payload not found in the application cache')) do |c|
 
       - c.with_body do
-        - enable_service_ping_link_url = help_page_path('user/admin_area/settings/usage_statistics', anchor: 'enable-or-disable-usage-statistics')
+        - enable_service_ping_link_url = help_page_path('administration/settings/usage_statistics', anchor: 'enable-or-disable-usage-statistics')
         - enable_service_ping_link = '<a href="%{url}">'.html_safe % { url: enable_service_ping_link_url }
         - generate_manually_link_url = help_page_path('development/internal_analytics/service_ping/troubleshooting', anchor: 'generate-service-ping')
         - generate_manually_link = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: generate_manually_link_url }
diff --git a/app/views/shared/_registration_features_discovery_message.html.haml b/app/views/shared/_registration_features_discovery_message.html.haml
index 053c511830c..6e386866dfb 100644
--- a/app/views/shared/_registration_features_discovery_message.html.haml
+++ b/app/views/shared/_registration_features_discovery_message.html.haml
@@ -1,5 +1,5 @@
 - feature_title = local_assigns.fetch(:feature_title, s_('RegistrationFeatures|use this feature'))
-- registration_features_docs_path = help_page_path('user/admin_area/settings/usage_statistics.md', anchor: 'registration-features-program')
+- registration_features_docs_path = help_page_path('administration/settings/usage_statistics.md', anchor: 'registration-features-program')
 - registration_features_link_start = '<a href="%{url}" target="_blank">'.html_safe % { url: registration_features_docs_path }
 
 %div
diff --git a/config/feature_flags/development/enable_shared_runners_for_descendants.yml b/config/feature_flags/development/enable_shared_runners_for_descendants.yml
deleted file mode 100644
index 623057e6134..00000000000
--- a/config/feature_flags/development/enable_shared_runners_for_descendants.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: enable_shared_runners_for_descendants
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124728
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/416379
-milestone: '16.2'
-type: development
-group: group::runner
-default_enabled: false
diff --git a/config/feature_flags/development/fix_new_blobs_memoization.yml b/config/feature_flags/development/fix_new_blobs_memoization.yml
deleted file mode 100644
index 128dad3a49c..00000000000
--- a/config/feature_flags/development/fix_new_blobs_memoization.yml
+++ /dev/null
@@ -1,8 +0,0 @@
----
-name: fix_new_blobs_memoization
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125241
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/417632
-milestone: '16.2'
-type: development
-group: group::source code
-default_enabled: false
diff --git a/config/feature_flags/development/ml_experiment_tracking.yml b/config/feature_flags/development/ml_experiment_tracking.yml
index 19f14196591..b39c7395bbc 100644
--- a/config/feature_flags/development/ml_experiment_tracking.yml
+++ b/config/feature_flags/development/ml_experiment_tracking.yml
@@ -5,5 +5,5 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/371669
 milestone: '15.6'
 type: development
 group: group::incubation
-default_enabled: false
+default_enabled: true
 log_state_changes: true
diff --git a/config/initializers/1_settings.rb b/config/initializers/1_settings.rb
index c36f273f35a..50d26236a29 100644
--- a/config/initializers/1_settings.rb
+++ b/config/initializers/1_settings.rb
@@ -840,15 +840,18 @@ Gitlab.ee do
   Settings.cron_jobs['abandoned_trial_emails'] ||= {}
   Settings.cron_jobs['abandoned_trial_emails']['cron'] ||= "0 1 * * *"
   Settings.cron_jobs['abandoned_trial_emails']['job_class'] = 'Emails::AbandonedTrialEmailsCronWorker'
-  Settings.cron_jobs['package_metadata_sync_worker'] ||= {}
-  Settings.cron_jobs['package_metadata_sync_worker']['cron'] ||= "*/5 * * * *"
-  Settings.cron_jobs['package_metadata_sync_worker']['job_class'] = 'PackageMetadata::SyncWorker'
+  Settings.cron_jobs['package_metadata_licenses_sync_worker'] ||= {}
+  Settings.cron_jobs['package_metadata_licenses_sync_worker']['cron'] ||= "*/5 * * * *"
+  Settings.cron_jobs['package_metadata_licenses_sync_worker']['job_class'] = 'PackageMetadata::LicensesSyncWorker'
   Settings.cron_jobs['compliance_violations_consistency_worker'] ||= {}
   Settings.cron_jobs['compliance_violations_consistency_worker']['cron'] ||= '0 1 * * *'
   Settings.cron_jobs['compliance_violations_consistency_worker']['job_class'] = 'ComplianceManagement::MergeRequests::ComplianceViolationsConsistencyWorker'
   Settings.cron_jobs['users_delete_unconfirmed_users_worker'] ||= {}
   Settings.cron_jobs['users_delete_unconfirmed_users_worker']['cron'] ||= '0 * * * *'
   Settings.cron_jobs['users_delete_unconfirmed_users_worker']['job_class'] = 'Users::UnconfirmedUsersDeletionCronWorker'
+  Settings.cron_jobs['package_metadata_advisories_sync_worker'] ||= {}
+  Settings.cron_jobs['package_metadata_advisories_sync_worker']['cron'] ||= "*/5 * * * *"
+  Settings.cron_jobs['package_metadata_advisories_sync_worker']['job_class'] = 'PackageMetadata::AdvisoriesSyncWorker'
 
   Gitlab.com do
     Settings.cron_jobs['free_user_cap_backfill_notification_jobs_worker'] ||= {}
diff --git a/config/webpack.config.js b/config/webpack.config.js
index 1c6ac0bc843..39dc08d15c6 100644
--- a/config/webpack.config.js
+++ b/config/webpack.config.js
@@ -311,6 +311,7 @@ let shouldExcludeFromCompliling = (modulePath) =>
 if (EXPLICIT_VUE_VERSION) {
   Object.assign(alias, {
     '@gitlab/ui/scss_to_js': path.join(ROOT_PATH, 'node_modules/@gitlab/ui/scss_to_js'),
+    '@gitlab/ui/dist/tokens/js': path.join(ROOT_PATH, 'node_modules/@gitlab/ui/dist/tokens/js'),
     '@gitlab/ui/dist': '@gitlab/ui/src',
     '@gitlab/ui': '@gitlab/ui/src',
   });
diff --git a/db/migrate/20230620101808_change_default_value_for_distro_version.rb b/db/migrate/20230620101808_change_default_value_for_distro_version.rb
new file mode 100644
index 00000000000..f0da7cfaba7
--- /dev/null
+++ b/db/migrate/20230620101808_change_default_value_for_distro_version.rb
@@ -0,0 +1,13 @@
+# frozen_string_literal: true
+
+class ChangeDefaultValueForDistroVersion < Gitlab::Database::Migration[2.1]
+  def up
+    change_column_default :pm_affected_packages, :distro_version, from: nil, to: ''
+    change_column_null :pm_affected_packages, :distro_version, false
+  end
+
+  def down
+    change_column_default :pm_affected_packages, :distro_version, from: '', to: nil
+    change_column_null :pm_affected_packages, :distro_version, true
+  end
+end
diff --git a/db/post_migrate/20230705145827_drop_wrong_index_on_vulnerability_occurrences.rb b/db/post_migrate/20230705145827_drop_wrong_index_on_vulnerability_occurrences.rb
index e8a41cf9f04..6b4089f72fe 100644
--- a/db/post_migrate/20230705145827_drop_wrong_index_on_vulnerability_occurrences.rb
+++ b/db/post_migrate/20230705145827_drop_wrong_index_on_vulnerability_occurrences.rb
@@ -8,7 +8,7 @@ class DropWrongIndexOnVulnerabilityOccurrences < Gitlab::Database::Migration[2.1
   def up
     # We do not want to drop this from Gitlab.com
     # because it was created correctly there
-    return if Gitlab.com?
+    return if Gitlab.com? && !Gitlab.dev_or_test_env?
 
     remove_concurrent_index_by_name(
       :vulnerability_occurrences,
diff --git a/db/schema_migrations/20230620101808 b/db/schema_migrations/20230620101808
new file mode 100644
index 00000000000..ecb74b18870
--- /dev/null
+++ b/db/schema_migrations/20230620101808
@@ -0,0 +1 @@
+8c797f079ce4536559bbe73b9c18540f5793dc725eb970ac23bfeb1578f8adc2
\ No newline at end of file
diff --git a/db/structure.sql b/db/structure.sql
index 05b1d298943..b69f0da4a54 100644
--- a/db/structure.sql
+++ b/db/structure.sql
@@ -20327,7 +20327,7 @@ CREATE TABLE pm_affected_packages (
     updated_at timestamp with time zone NOT NULL,
     purl_type smallint NOT NULL,
     package_name text NOT NULL,
-    distro_version text,
+    distro_version text DEFAULT ''::text NOT NULL,
     solution text,
     affected_range text NOT NULL,
     fixed_versions text[] DEFAULT '{}'::text[],
diff --git a/doc/administration/analytics/dev_ops_reports.md b/doc/administration/analytics/dev_ops_reports.md
index 367f12ea8a1..1dcee5ec03d 100644
--- a/doc/administration/analytics/dev_ops_reports.md
+++ b/doc/administration/analytics/dev_ops_reports.md
@@ -21,14 +21,14 @@ To see DevOps Reports:
 > [Renamed](https://gitlab.com/gitlab-org/gitlab/-/issues/20976) from Conversational Development Index in GitLab 12.6.
 
 NOTE:
-To see the DevOps score, you must activate your GitLab instance's [Service Ping](../../user/admin_area/settings/usage_statistics.md#service-ping). DevOps Score is a comparative tool, so your score data must be centrally processed by GitLab Inc. first.
+To see the DevOps score, you must activate your GitLab instance's [Service Ping](../settings/usage_statistics.md#service-ping). DevOps Score is a comparative tool, so your score data must be centrally processed by GitLab Inc. first.
 
 You can use the DevOps score to compare your DevOps status to other organizations.
 
 The DevOps Score tab displays usage of major GitLab features on your instance over
 the last 30 days, averaged over the number of billable users in that time period.
 You can also see the Leader usage score, calculated from top-performing instances based on
-[Service Ping data](../../user/admin_area/settings/usage_statistics.md#service-ping) that GitLab has collected.
+[Service Ping data](../settings/usage_statistics.md#service-ping) that GitLab has collected.
 Your score is compared to the lead score of each feature and then expressed
 as a percentage at the bottom of said feature. Your overall **DevOps Score** is an average of your
 feature scores.
diff --git a/doc/administration/audit_event_streaming/graphql_api.md b/doc/administration/audit_event_streaming/graphql_api.md
index 7eec352abf3..7f0b0e67f6d 100644
--- a/doc/administration/audit_event_streaming/graphql_api.md
+++ b/doc/administration/audit_event_streaming/graphql_api.md
@@ -15,6 +15,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - User-specified verification token API support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360813) in GitLab 15.4.
 > - APIs for custom HTTP headers for instance level streaming destinations [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404560) in GitLab 16.1 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
 > - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
+> - User-specified destination name API support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/413894) in GitLab 16.2.
 
 Audit event streaming destinations can be maintained using a GraphQL API.
 
@@ -39,6 +40,7 @@ mutation {
     errors
     externalAuditEventDestination {
       id
+      name
       destinationUrl
       verificationToken
       group {
@@ -60,6 +62,28 @@ mutation {
     errors
     externalAuditEventDestination {
       id
+      name
+      destinationUrl
+      verificationToken
+      group {
+        name
+      }
+    }
+  }
+}
+```
+
+You can optionally specify your own destination name (instead of the default GitLab-generated one) using the GraphQL
+`externalAuditEventDestinationCreate`
+mutation. Name length must not exceed 72 characters and trailing whitespace are not trimmed. This value should be unique scoped to a group. For example:
+
+```graphql
+mutation {
+  externalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", name: "destination-name-here", groupPath: "my-group" }) {
+    errors
+    externalAuditEventDestination {
+      id
+      name
       destinationUrl
       verificationToken
       group {
@@ -112,6 +136,7 @@ mutation {
     instanceExternalAuditEventDestination {
       destinationUrl
       id
+      name
       verificationToken
     }
   }
@@ -123,6 +148,24 @@ Event streaming is enabled if:
 - The returned `errors` object is empty.
 - The API responds with `200 OK`.
 
+You can optionally specify your own destination name (instead of the default GitLab-generated one) using the GraphQL
+`instanceExternalAuditEventDestinationCreate`
+mutation. Name length must not exceed 72 characters and trailing whitespace are not trimmed. This value should be unique. For example:
+
+```graphql
+mutation {
+  instanceExternalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", name: "destination-name-here"}) {
+    errors
+    instanceExternalAuditEventDestination {
+      destinationUrl
+      id
+      name
+      verificationToken
+    }
+  }
+}
+```
+
 Instance administrators can add an HTTP header using the GraphQL `auditEventsStreamingInstanceHeadersCreate` mutation. You can retrieve the destination ID
 by [listing all the streaming destinations](#list-streaming-destinations) for the instance or from the mutation above.
 
@@ -201,6 +244,7 @@ query {
         destinationUrl
         verificationToken
         id
+        name
         headers {
           nodes {
             key
@@ -238,6 +282,7 @@ query {
   instanceExternalAuditEventDestinations {
     nodes {
       id
+      name
       destinationUrl
       verificationToken
       headers {
@@ -304,8 +349,20 @@ by [listing all the custom HTTP headers](#list-streaming-destinations) for the g
 
 ```graphql
 mutation {
-  externalAuditEventDestinationDestroy(input: { id: destination }) {
+  externalAuditEventDestinationUpdate(input: { 
+    id:"gid://gitlab/AuditEvents::ExternalAuditEventDestination/1", 
+    destinationUrl: "https://www.new-domain.com/webhook",
+    name: "destination-name"} ) {
     errors
+    externalAuditEventDestination {
+      id
+      name
+      destinationUrl
+      verificationToken
+      group {
+        name
+      }
+    }
   }
 }
 ```
@@ -347,11 +404,15 @@ by [listing all the external destinations](#list-streaming-destinations) for the
 
 ```graphql
 mutation {
-  instanceExternalAuditEventDestinationUpdate(input: { id: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1", destinationUrl: "https://www.new-domain.com/webhook"}) {
+  instanceExternalAuditEventDestinationUpdate(input: { 
+    id: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1",
+    destinationUrl: "https://www.new-domain.com/webhook",
+    name: "destination-name"}) {
     errors
     instanceExternalAuditEventDestination {
       destinationUrl
       id
+      name
       verificationToken
     }
   }
diff --git a/doc/administration/settings/usage_statistics.md b/doc/administration/settings/usage_statistics.md
new file mode 100644
index 00000000000..3b3a297b9d6
--- /dev/null
+++ b/doc/administration/settings/usage_statistics.md
@@ -0,0 +1,230 @@
+---
+stage: Analytics
+group: Analytics Instrumentation
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Usage statistics **(FREE SELF)**
+
+GitLab Inc. periodically collects information about your instance in order
+to perform various actions.
+
+All usage statistics are [opt-out](#enable-or-disable-usage-statistics).
+
+## Service Ping
+
+Service Ping is a process that collects and sends a weekly payload to GitLab Inc.
+For more information, see the [Service Ping guide](../../development/internal_analytics/service_ping/index.md). When Service Ping is enabled, GitLab gathers data from other instances and enables certain [instance-level analytics features](../../user/analytics/index.md)
+that are dependent on Service Ping.
+
+### Why enable Service Ping?
+
+The main purpose of Service Ping is to build a better GitLab. We collect data about how GitLab is used
+to understand feature or stage adoption and usage. This data gives an insight into how GitLab adds
+value and helps our team understand the reasons why people use GitLab, and with this knowledge we're able to make better product decisions.
+
+There are several other benefits to enabling Service Ping:
+
+- Analyze the users' activities over time of your GitLab installation.
+- A [DevOps Score](../analytics/dev_ops_reports.md) to give you an overview of your entire instance's adoption of concurrent DevOps from planning to monitoring.
+- More proactive support (assuming that our [Customer Success Managers (CSMs)](https://handbook.gitlab.com/job-families/sales/customer-success-management/) and support organization used the data to deliver more value).
+- Insight and advice into how to get the most value out of your investment in GitLab.
+- Reports that show how you compare against other similar organizations (anonymized), with specific advice and recommendations on how to improve your DevOps processes.
+- Participation in our [Registration Features Program](#registration-features-program) to receive free paid features.
+
+## Registration Features Program
+
+> Introduced in GitLab 14.1.
+
+In GitLab versions 14.1 and later, GitLab Free customers with a self-managed instance running
+GitLab Enterprise Edition can receive paid features by registering with GitLab and sending us
+activity data through Service Ping. Features introduced here do not remove the feature from its paid
+tier. Users can continue to access the features in a paid tier without sharing usage data.
+
+### Features available in 14.1 and later
+
+- [Email from GitLab](../../user/admin_area/email_from_gitlab.md).
+
+### Features available in 14.4 and later
+
+- [Repository size limit](../../administration/settings/account_and_limit_settings.md#repository-size-limit).
+- [Group access restriction by IP address](../../user/group/access_and_permissions.md#restrict-group-access-by-ip-address).
+
+### Features available in 16.0 and later
+
+- [View description change history](../../user/discussions/index.md#view-description-change-history).
+- [Maintenance mode](../maintenance_mode/index.md).
+- [Configurable issue boards](../../user/project/issue_board.md#configurable-issue-boards).
+- [Coverage-guided fuzz testing](../../user/application_security/coverage_fuzzing/index.md).
+- [Password complexity requirements](../../administration/settings/sign_up_restrictions.md#password-complexity-requirements).
+
+NOTE:
+Registration is not yet required for participation, but may be added in a future milestone.
+
+### Enable registration features
+
+1. Sign in as a user with administrator access.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Metrics and profiling**.
+1. Expand the **Usage statistics** section.
+1. If not enabled, select the **Enable Service Ping** checkbox.
+1. Select the **Enable Registration Features** checkbox.
+1. Select **Save changes**.
+
+## Version check
+
+If enabled, version check informs you if a new version is available and the
+importance of it through a status. The status displays on the help pages (`/help`)
+for all authenticated users, and on the Admin Area pages. The statuses are:
+
+- Green: You are running the latest version of GitLab.
+- Orange: An updated version of GitLab is available.
+- Red: The version of GitLab you are running is vulnerable. You should install
+  the latest version with security fixes as soon as possible.
+
+![Orange version check example](../../user/admin_area/settings/img/update-available.png)
+
+GitLab Inc. collects your instance's version and hostname (through the HTTP
+referer) as part of the version check. No other information is collected.
+
+This information is used, among other things, to identify to which versions
+patches must be backported, making sure active GitLab instances remain
+secure.
+
+If you [disable version check](#enable-or-disable-usage-statistics), this information isn't collected.
+
+### Request flow example
+
+The following example shows a basic request/response flow between a
+self-managed GitLab instance and the GitLab Version Application:
+
+```mermaid
+sequenceDiagram
+    participant GitLab instance
+    participant Version Application
+    GitLab instance->>Version Application: Is there a version update?
+    loop Version Check
+        Version Application->>Version Application: Record version info
+    end
+    Version Application->>GitLab instance: Response (PNG/SVG)
+```
+
+## Configure your network
+
+To send usage statistics to GitLab Inc., you must allow network traffic from your
+GitLab instance to the host `version.gitlab.com` on port `443`.
+
+If your GitLab instance is behind a proxy, set the appropriate
+[proxy configuration variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html).
+
+## Enable or disable usage statistics
+
+To enable or disable Service Ping and version check:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Metrics and profiling**.
+1. Expand **Usage statistics**.
+1. Select or clear the **Enable version check** and **Enable Service Ping** checkboxes.
+1. Select **Save changes**.
+
+NOTE:
+Service Ping settings only control whether the data is being shared with GitLab, or used only internally.
+Even if you disable Service Ping, the `gitlab_service_ping_worker` background job still periodically generates a Service Ping payload for your instance.
+The payload is available in the [Service Usage data](#manually-upload-service-ping-payload) admin section.
+
+## Disable usage statistics with the configuration file
+
+NOTE:
+The method to disable Service Ping in the GitLab configuration file does not work in
+GitLab versions 9.3 to 13.12.3. For more information about how to disable it, see [troubleshooting](../../development/internal_analytics/service_ping/troubleshooting.md#cannot-disable-service-ping-with-the-configuration-file).
+
+To disable Service Ping and prevent it from being configured in the future through
+the Admin Area:
+
+**For installations using the Linux package:**
+
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   gitlab_rails['usage_ping_enabled'] = false
+   ```
+
+1. Reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+**For installations from source:**
+
+1. Edit `/home/git/gitlab/config/gitlab.yml`:
+
+   ```yaml
+   production: &base
+     # ...
+     gitlab:
+       # ...
+       usage_ping_enabled: false
+   ```
+
+1. Restart GitLab:
+
+   ```shell
+   sudo service gitlab restart
+   ```
+
+## View the Service Ping payload
+
+You can view the exact JSON payload sent to GitLab Inc. in the Admin Area. To view the payload:
+
+1. Sign in as a user with administrator access.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Metrics and profiling**.
+1. Expand the **Usage statistics** section.
+1. Select **Preview payload**.
+
+For an example payload, see [Example Service Ping payload](../../development/internal_analytics/service_ping/index.md#example-service-ping-payload).
+
+## Manually upload Service Ping payload
+
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/7388) in GitLab 14.8 with a flag named `admin_application_settings_service_usage_data_center`. Disabled by default.
+> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83265) in GitLab 14.10.
+
+You can upload the Service Ping payload to GitLab even if your instance doesn't have internet access,
+or if the Service Ping [cron job](../../development/internal_analytics/service_ping/index.md#how-service-ping-works) is not enabled.
+
+To upload the payload manually:
+
+1. Sign in as a user with administrator access.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Service** usage data.
+1. Select **Download payload**.
+1. Save the JSON file.
+1. Visit [Service usage data center](https://version.gitlab.com/usage_data/new).
+1. Select **Choose file** and choose the file from p5.
+1. Select **Upload**.
+
+The uploaded file is encrypted and sent using secure HTTPS protocol. HTTPS creates a secure
+communication channel between web browser and the server, and protects transmitted data against man-in-the-middle attacks.
+
+If there are problems with the manual upload:
+
+1. Open a confidential issue in the [security fork of version app project](https://gitlab.com/gitlab-org/security/version.gitlab.com).
+1. Attach the JSON payload if possible.
+1. Tag `@gitlab-org/analytics-section/analytics-instrumentation` who will triage the issue.
+
+<!-- ## Troubleshooting
+
+Include any troubleshooting steps that you can foresee. If you know beforehand what issues
+one might have when setting this up, or when something is changed, or on upgrading, it's
+important to describe those, too. Think of things that may go wrong and include them here.
+This is important to minimize requests for support, and to avoid doc comments with
+questions that you know someone might ask.
+
+Each scenario can be a third-level heading, for example `### Getting error message X`.
+If you have none to add when creating a doc, leave this section in place
+but commented out to help encourage others to add to it in the future. -->
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 665d303137c..3fff01abf3e 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -26199,6 +26199,7 @@ Representation of whether a GitLab merge request can be merged.
 | ----- | ----------- |
 | <a id="mergestrategyenumadd_to_merge_train_when_pipeline_succeeds"></a>`ADD_TO_MERGE_TRAIN_WHEN_PIPELINE_SUCCEEDS` | Use the add_to_merge_train_when_pipeline_succeeds merge strategy. |
 | <a id="mergestrategyenummerge_train"></a>`MERGE_TRAIN` | Use the merge_train merge strategy. |
+| <a id="mergestrategyenummerge_when_checks_pass"></a>`MERGE_WHEN_CHECKS_PASS` | Use the merge_when_checks_pass merge strategy. |
 | <a id="mergestrategyenummerge_when_pipeline_succeeds"></a>`MERGE_WHEN_PIPELINE_SUCCEEDS` | Use the merge_when_pipeline_succeeds merge strategy. |
 
 ### `MilestoneSort`
diff --git a/doc/ci/runners/runners_scope.md b/doc/ci/runners/runners_scope.md
index 664d255dcac..840eb7fe93b 100644
--- a/doc/ci/runners/runners_scope.md
+++ b/doc/ci/runners/runners_scope.md
@@ -139,10 +139,6 @@ To disable shared runners for a group:
 1. Optional. To allow shared runners to be enabled for individual projects or subgroups,
    select **Allow projects and subgroups to override the group setting**.
 
-NOTE:
-If you re-enable the shared runners for a group after you disable them, a user with the
-Owner or Maintainer role must manually change this setting for each project subgroup or project.
-
 ### How shared runners pick jobs
 
 Shared runners process jobs by using a fair usage queue. This queue prevents
diff --git a/doc/development/avoiding_required_stops.md b/doc/development/avoiding_required_stops.md
new file mode 100644
index 00000000000..0308e0c30c0
--- /dev/null
+++ b/doc/development/avoiding_required_stops.md
@@ -0,0 +1,137 @@
+---
+stage: Systems
+group: Distribution
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Avoiding required stops
+
+Required stops are any changes to GitLab [components](architecture.md) or
+dependencies that result in the need to upgrade to and stop at a specific
+`major.minor` version when [upgrading GitLab](../update/index.md).
+
+While Development maintains a [maintainenance policy](../policy/maintenance.md)
+that results in a three-release (3 month) backport window - GitLab maintains a
+much longer window of [version support](https://about.gitlab.com/support/statement-of-support/#version-support)
+that includes the current major version, as well as the two previous major
+versions. Based on the schedule of previous major releases, GitLab customers can
+lag behind the current release for up to three years and still expect to have
+support for upgrades.
+
+For example, a GitLab user upgrading from GitLab 14.0.12 to GitLab 16.1,
+which is a fully supported [upgrade path](../update/index.md#upgrade-paths), may have
+the following required stops: `14.3.6`, `14.9.5`, `14.10.5`, `15.0.5`, `15.1.6`,
+`15.4.6`, and `15.11.11` before upgrading to the latest `16.1.z` version.
+
+Past required stops have not been discovered for months after their introduction,
+often as the result of extensive troubleshooting and assistance from Support
+Engineers, Customer Success Managers, and Development Engineers as users upgrade
+across greater than 1-3 minor releases.
+
+Wherever possible, a required stop should be avoided. If it can't be avoided,
+the required stop should be aligned to a _scheduled_ required stop.
+
+Scheduled required stops are often implemented for the previous `major`.`minor`
+release just prior to a `major` version release in order to accomodate multiple
+[planned deprecations](../update/terminology.md#deprecation) and known
+[breaking changes](../update/terminology.md#breaking-change).
+
+Additionally, as of GitLab 16, we have introduced
+[_scheduled_ `major`.`minor` required stops](../update/index.md#upgrade-paths):
+
+>>>
+During GitLab 16.x, we are scheduling two or three required upgrade stops.
+
+We will give at least two milestones of notice when we schedule a required
+upgrade stop. The first planned required upgrade stop is scheduled for GitLab
+16.3. If nothing is introduced requiring an upgrade stop, GitLab 16.3 will be
+treated as a regular upgrade.
+>>>
+
+## Causes of required stops
+
+### Inaccurate assumptions about completed migrations
+
+The majority of required stops are due to assumptions about the state of the
+data model in a given release, usually in the form of interdependent database
+migrations, or code changes that assume that schema changes introduced in
+prior migrations have completed by the time the code loads.
+
+Designing changes and migrations for [backwards compatibility between versions](multi_version_compatibility.md) can mitigate stop concerns with continuous or
+"zero-downtime" upgrades. However, the **contract** phase will likely introduce
+a required stop when a migration/code change is introduced that requires
+that background migrations have completed before running or loading.
+
+WARNING:
+If you're considering adding or removing a migration, or introducing code that
+assumes that migrations have completed in a given release, first review
+the database-related documentation on [required stops](database/required_stops.md).
+
+#### Examples
+
+- GitLab `12.1`: Introduced a background migration changing `merge_status` in
+  MergeRequests depending on the `state` value. The `state` attribute was removed
+  in `12.10`. It took until `13.6` to document the required stop.
+- GitLab `13.8`: Includes a background migration to deal with duplicate service
+  records. In `13.9`, a unique index was applied in another migration that
+  depended on the background migration completing. Not discovered/documented until
+  GitLab `14.3`
+- GitLab `14.3`: Includes a potentially long-running background migration against
+  `merge_request_diff_commits` that was foregrounded in `14.5`. This change resulted in
+   extensive downtime for users with large GitLab installations. Not documented
+   until GitLab `15.1`
+- GitLab `14.9`: Includes a batched background migration for `namespaces` and `projects`
+  that needs to finish before another batched background migration added in `14.10` executes,
+  forcing a required stop. The migration can take hours or days to complete on
+  large GitLab installations.
+
+Additional details as well as links to related issues and merge requests can be
+found in: [Issue: Put in place measures to avoid addition/proliferation of GitLab upgrade path stops](https://gitlab.com/gitlab-org/gitlab/-/issues/375553)
+
+### Removal of code workarounds and mitigations
+
+Similar to assumptions about the data model/schema/migration state, required
+`major.minor` stops have been introduced due to the intentional removal of
+code implemented to workaround previously discovered issues.
+
+#### Examples
+
+- GitLab `13.1`: A security fix in Rails `6.0.3.1` introduced a CSRF token change
+  (causing a canary environment incident). We introduced code to maintain acceptance
+  of previously generated tokens, and removed the code in `13.2`, creating a known
+  required stop in `13.1`.
+- GitLab `15.4`: Introduces a migration to fix an inaccurate `expires_at` timestamp
+  for job artifacts that had been mitigated in code since GitLab `14.9`. The
+  workaround was removed in GitLab `15.6`, causing `15.4` to be a required stop.
+
+### Deprecations
+
+Deprecations, particularly [breaking changes](../update/terminology.md#breaking-change)
+can also cause required stops if they introduce long migration delays or require
+manual actions on the part of GitLab administrators.
+
+These are generally accepted as a required stop around a major release, either
+stopping at the latest `major.minor` release immediately proceeding
+a new `major` release, and potentially the lastest `major.0` patch release, and
+to date, discovered required stops related to deprecations have been limited to
+these releases.
+
+#### Examples
+
+Examples of deprecations are too numerous to be listed here, but can found
+in the [deprecations and removals by version](../update/deprecations.md) as well
+as the [version-specific upgrading instructions](../update/index.md#version-specific-upgrading-instructions),
+[version-specific changes for the GitLab package (Omnibus)](../update/package/index.md#version-specific-changes),
+and [GitLab chart upgrade notes](https://docs.gitlab.com/charts/installation/upgrade.html).
+
+## Further reading
+
+- [Documentation: Database - Adding required stops](database/required_stops.md)
+- [Documentation: Upgrading GitLab](../update/index.md)
+  - [Package (Omnibus) upgrade](../update/package/index.md)
+  - [Docker upgrade](../install/docker.md#upgrade)
+  - [GitLab chart](https://docs.gitlab.com/charts/installation/upgrade.html)
+- [Issue: Put in place measures to avoid addition/proliferation of GitLab upgrade path stops](https://gitlab.com/gitlab-org/gitlab/-/issues/375553)
+- [Issue: Brainstorm ways for background migrations to be finalized without introducing a required upgrade step](https://gitlab.com/gitlab-org/gitlab/-/issues/357561)
+- [Issue: Scheduled required paths for GitLab upgrades to improve UX](https://gitlab.com/gitlab-org/gitlab/-/issues/358417)
+- [Epic: GitLab Releases and Maintenance policies](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/988)
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 95d2c8c66bb..6aedb18c15d 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -400,6 +400,8 @@ Maintainers are the DRI of assuring that the acceptance criteria of a merge requ
 In general, [quality is everyone's responsibility](https://about.gitlab.com/handbook/engineering/quality/),
 but maintainers of an MR are held responsible for **ensuring** that an MR meets those general quality standards.
 
+This includes [avoiding the creation of technical debt in follow-up issues](contributing/issue_workflow.md#technical-debt-in-follow-up-issues).
+
 If a maintainer feels that an MR is substantial enough, or requires a [domain expert](#domain-experts),
 maintainers have the discretion to request a review from another reviewer, or maintainer. Here are some
 examples of maintainers proactively doing this during review:
diff --git a/doc/development/development_processes.md b/doc/development/development_processes.md
index c5d60d18419..4ce9df8d7da 100644
--- a/doc/development/development_processes.md
+++ b/doc/development/development_processes.md
@@ -22,6 +22,7 @@ Must-reads:
 
 Complementary reads:
 
+- [Avoiding required stops](avoiding_required_stops.md)
 - [Contribute to GitLab](contributing/index.md)
 - [Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer)
 - [Patch release process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md#process-for-developers)
diff --git a/doc/development/internal_analytics/service_ping/index.md b/doc/development/internal_analytics/service_ping/index.md
index 69d37f0dae2..22e66a247c9 100644
--- a/doc/development/internal_analytics/service_ping/index.md
+++ b/doc/development/internal_analytics/service_ping/index.md
@@ -22,7 +22,7 @@ and sales teams understand how GitLab is used. The data helps to:
 Service Ping information is not anonymous. It's linked to the instance's hostname, but does
 not contain project names, usernames, or any other specific data.
 
-Service Ping is enabled by default. However, you can [disable](../../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics) it on any self-managed instance. When Service Ping is enabled, GitLab gathers data from the other instances and can show your instance's usage statistics to your users.
+Service Ping is enabled by default. However, you can [disable](../../../administration/settings/usage_statistics.md#enable-or-disable-usage-statistics) it on any self-managed instance. When Service Ping is enabled, GitLab gathers data from the other instances and can show your instance's usage statistics to your users.
 
 ## Service Ping terminology
 
diff --git a/doc/development/internal_analytics/service_ping/metrics_dictionary.md b/doc/development/internal_analytics/service_ping/metrics_dictionary.md
index 7b7468740dc..90a99d1ec56 100644
--- a/doc/development/internal_analytics/service_ping/metrics_dictionary.md
+++ b/doc/development/internal_analytics/service_ping/metrics_dictionary.md
@@ -150,7 +150,7 @@ For more information about the aggregation type of each feature, see the [`commo
 We use the following categories to classify a metric:
 
 - `operational`: Required data for operational purposes.
-- `optional`: Default value for a metric. Data that is optional to collect. This can be [enabled or disabled](../../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics) in the Admin Area.
+- `optional`: Default value for a metric. Data that is optional to collect. This can be [enabled or disabled](../../../administration/settings/usage_statistics.md#enable-or-disable-usage-statistics) in the Admin Area.
 - `subscription`: Data related to licensing.
 - `standard`: Standard set of identifiers that are included when collecting data.
 
diff --git a/doc/topics/offline/quick_start_guide.md b/doc/topics/offline/quick_start_guide.md
index 27ca8784876..dd739fdaf77 100644
--- a/doc/topics/offline/quick_start_guide.md
+++ b/doc/topics/offline/quick_start_guide.md
@@ -204,7 +204,7 @@ Version Check and Service Ping improve the GitLab user experience and ensure tha
 users are on the most up-to-date instances of GitLab. These two services can be turned off for offline
 environments so that they do not attempt and fail to reach out to GitLab services.
 
-For more information, see [Enable or disable usage statistics](../../user/admin_area/settings/usage_statistics.md#enable-or-disable-usage-statistics).
+For more information, see [Enable or disable usage statistics](../../administration/settings/usage_statistics.md#enable-or-disable-usage-statistics).
 
 ### Configure NTP
 
diff --git a/doc/user/admin_area/settings/usage_statistics.md b/doc/user/admin_area/settings/usage_statistics.md
index a31d90d838c..5b2afd3ad90 100644
--- a/doc/user/admin_area/settings/usage_statistics.md
+++ b/doc/user/admin_area/settings/usage_statistics.md
@@ -1,230 +1,11 @@
 ---
-stage: Analytics
-group: Analytics Instrumentation
-info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+redirect_to: '../../../administration/settings/usage_statistics.md'
+remove_date: '2023-10-13'
 ---
 
-# Usage statistics **(FREE SELF)**
+This document was moved to [another location](../../../administration/settings/usage_statistics.md).
 
-GitLab Inc. periodically collects information about your instance in order
-to perform various actions.
-
-All usage statistics are [opt-out](#enable-or-disable-usage-statistics).
-
-## Service Ping
-
-Service Ping is a process that collects and sends a weekly payload to GitLab Inc.
-For more information, see the [Service Ping guide](../../../development/internal_analytics/service_ping/index.md). When Service Ping is enabled, GitLab gathers data from other instances and enables certain [instance-level analytics features](../analytics/index.md)
-that are dependent on Service Ping.
-
-### Why enable Service Ping?
-
-The main purpose of Service Ping is to build a better GitLab. We collect data about how GitLab is used
-to understand feature or stage adoption and usage. This data gives an insight into how GitLab adds
-value and helps our team understand the reasons why people use GitLab, and with this knowledge we're able to make better product decisions.
-
-There are several other benefits to enabling Service Ping:
-
-- Analyze the users' activities over time of your GitLab installation.
-- A [DevOps Score](../../../administration/analytics/dev_ops_reports.md) to give you an overview of your entire instance's adoption of concurrent DevOps from planning to monitoring.
-- More proactive support (assuming that our [Customer Success Managers (CSMs)](https://handbook.gitlab.com/job-families/sales/customer-success-management/) and support organization used the data to deliver more value).
-- Insight and advice into how to get the most value out of your investment in GitLab.
-- Reports that show how you compare against other similar organizations (anonymized), with specific advice and recommendations on how to improve your DevOps processes.
-- Participation in our [Registration Features Program](#registration-features-program) to receive free paid features.
-
-## Registration Features Program
-
-> Introduced in GitLab 14.1.
-
-In GitLab versions 14.1 and later, GitLab Free customers with a self-managed instance running
-GitLab Enterprise Edition can receive paid features by registering with GitLab and sending us
-activity data through Service Ping. Features introduced here do not remove the feature from its paid
-tier. Users can continue to access the features in a paid tier without sharing usage data.
-
-### Features available in 14.1 and later
-
-- [Email from GitLab](../email_from_gitlab.md).
-
-### Features available in 14.4 and later
-
-- [Repository size limit](../../../administration/settings/account_and_limit_settings.md#repository-size-limit).
-- [Group access restriction by IP address](../../group/access_and_permissions.md#restrict-group-access-by-ip-address).
-
-### Features available in 16.0 and later
-
-- [View description change history](../../../user/discussions/index.md#view-description-change-history).
-- [Maintenance mode](../../../administration/maintenance_mode/index.md).
-- [Configurable issue boards](../../project/issue_board.md#configurable-issue-boards).
-- [Coverage-guided fuzz testing](../../application_security/coverage_fuzzing/index.md).
-- [Password complexity requirements](../../../administration/settings/sign_up_restrictions.md#password-complexity-requirements).
-
-NOTE:
-Registration is not yet required for participation, but may be added in a future milestone.
-
-### Enable registration features
-
-1. Sign in as a user with administrator access.
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
-1. Select **Admin Area**.
-1. Select **Settings > Metrics and profiling**.
-1. Expand the **Usage statistics** section.
-1. If not enabled, select the **Enable Service Ping** checkbox.
-1. Select the **Enable Registration Features** checkbox.
-1. Select **Save changes**.
-
-## Version check
-
-If enabled, version check informs you if a new version is available and the
-importance of it through a status. The status displays on the help pages (`/help`)
-for all authenticated users, and on the Admin Area pages. The statuses are:
-
-- Green: You are running the latest version of GitLab.
-- Orange: An updated version of GitLab is available.
-- Red: The version of GitLab you are running is vulnerable. You should install
-  the latest version with security fixes as soon as possible.
-
-![Orange version check example](img/update-available.png)
-
-GitLab Inc. collects your instance's version and hostname (through the HTTP
-referer) as part of the version check. No other information is collected.
-
-This information is used, among other things, to identify to which versions
-patches must be backported, making sure active GitLab instances remain
-secure.
-
-If you [disable version check](#enable-or-disable-usage-statistics), this information isn't collected.
-
-### Request flow example
-
-The following example shows a basic request/response flow between a
-self-managed GitLab instance and the GitLab Version Application:
-
-```mermaid
-sequenceDiagram
-    participant GitLab instance
-    participant Version Application
-    GitLab instance->>Version Application: Is there a version update?
-    loop Version Check
-        Version Application->>Version Application: Record version info
-    end
-    Version Application->>GitLab instance: Response (PNG/SVG)
-```
-
-## Configure your network
-
-To send usage statistics to GitLab Inc., you must allow network traffic from your
-GitLab instance to the host `version.gitlab.com` on port `443`.
-
-If your GitLab instance is behind a proxy, set the appropriate
-[proxy configuration variables](https://docs.gitlab.com/omnibus/settings/environment-variables.html).
-
-## Enable or disable usage statistics
-
-To enable or disable Service Ping and version check:
-
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
-1. Select **Admin Area**.
-1. Select **Settings > Metrics and profiling**.
-1. Expand **Usage statistics**.
-1. Select or clear the **Enable version check** and **Enable Service Ping** checkboxes.
-1. Select **Save changes**.
-
-NOTE:
-Service Ping settings only control whether the data is being shared with GitLab, or used only internally.
-Even if you disable Service Ping, the `gitlab_service_ping_worker` background job still periodically generates a Service Ping payload for your instance.
-The payload is available in the [Service Usage data](#manually-upload-service-ping-payload) admin section.
-
-## Disable usage statistics with the configuration file
-
-NOTE:
-The method to disable Service Ping in the GitLab configuration file does not work in
-GitLab versions 9.3 to 13.12.3. For more information about how to disable it, see [troubleshooting](../../../development/internal_analytics/service_ping/troubleshooting.md#cannot-disable-service-ping-with-the-configuration-file).
-
-To disable Service Ping and prevent it from being configured in the future through
-the Admin Area:
-
-**For installations using the Linux package:**
-
-1. Edit `/etc/gitlab/gitlab.rb`:
-
-   ```ruby
-   gitlab_rails['usage_ping_enabled'] = false
-   ```
-
-1. Reconfigure GitLab:
-
-   ```shell
-   sudo gitlab-ctl reconfigure
-   ```
-
-**For installations from source:**
-
-1. Edit `/home/git/gitlab/config/gitlab.yml`:
-
-   ```yaml
-   production: &base
-     # ...
-     gitlab:
-       # ...
-       usage_ping_enabled: false
-   ```
-
-1. Restart GitLab:
-
-   ```shell
-   sudo service gitlab restart
-   ```
-
-## View the Service Ping payload
-
-You can view the exact JSON payload sent to GitLab Inc. in the Admin Area. To view the payload:
-
-1. Sign in as a user with administrator access.
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
-1. Select **Admin Area**.
-1. Select **Settings > Metrics and profiling**.
-1. Expand the **Usage statistics** section.
-1. Select **Preview payload**.
-
-For an example payload, see [Example Service Ping payload](../../../development/internal_analytics/service_ping/index.md#example-service-ping-payload).
-
-## Manually upload Service Ping payload
-
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/7388) in GitLab 14.8 with a flag named `admin_application_settings_service_usage_data_center`. Disabled by default.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83265) in GitLab 14.10.
-
-You can upload the Service Ping payload to GitLab even if your instance doesn't have internet access,
-or if the Service Ping [cron job](../../../development/internal_analytics/service_ping/index.md#how-service-ping-works) is not enabled.
-
-To upload the payload manually:
-
-1. Sign in as a user with administrator access.
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
-1. Select **Admin Area**.
-1. Select **Settings > Service** usage data.
-1. Select **Download payload**.
-1. Save the JSON file.
-1. Visit [Service usage data center](https://version.gitlab.com/usage_data/new).
-1. Select **Choose file** and choose the file from p5.
-1. Select **Upload**.
-
-The uploaded file is encrypted and sent using secure HTTPS protocol. HTTPS creates a secure
-communication channel between web browser and the server, and protects transmitted data against man-in-the-middle attacks.
-
-If there are problems with the manual upload:
-
-1. Open a confidential issue in the [security fork of version app project](https://gitlab.com/gitlab-org/security/version.gitlab.com).
-1. Attach the JSON payload if possible.
-1. Tag `@gitlab-org/analytics-section/analytics-instrumentation` who will triage the issue.
-
-<!-- ## Troubleshooting
-
-Include any troubleshooting steps that you can foresee. If you know beforehand what issues
-one might have when setting this up, or when something is changed, or on upgrading, it's
-important to describe those, too. Think of things that may go wrong and include them here.
-This is important to minimize requests for support, and to avoid doc comments with
-questions that you know someone might ask.
-
-Each scenario can be a third-level heading, for example `### Getting error message X`.
-If you have none to add when creating a doc, leave this section in place
-but commented out to help encourage others to add to it in the future. -->
+<!-- This redirect file can be deleted after <2023-10-13>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/user/application_security/policies/scan-execution-policies.md b/doc/user/application_security/policies/scan-execution-policies.md
index 3a1592e6abf..b84d4d2e49e 100644
--- a/doc/user/application_security/policies/scan-execution-policies.md
+++ b/doc/user/application_security/policies/scan-execution-policies.md
@@ -96,11 +96,8 @@ the following sections and tables provide an alternative.
 
 ## `pipeline` rule type
 
-> The `branch_type` field was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404774) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `security_policies_branch_type`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `security_policies_branch_type`.
-On GitLab.com, this feature is not available.
+> - The `branch_type` field was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404774) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `security_policies_branch_type`. Disabled by default.
+> - The `branch_type` field was [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/413062) in GitLab 16.2.
 
 This rule enforces the defined actions whenever the pipeline runs for a selected branch.
 
@@ -114,11 +111,8 @@ This rule enforces the defined actions whenever the pipeline runs for a selected
 
 ## `schedule` rule type
 
-> The `branch_type` field was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404774) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `security_policies_branch_type`. Disabled by default.
-
-FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `security_policies_branch_type`.
-On GitLab.com, this feature is not available.
+> - The `branch_type` field was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/404774) in GitLab 16.1 [with a flag](../../../administration/feature_flags.md) named `security_policies_branch_type`. Disabled by default.
+> - The `branch_type` field was [enabled on GitLab.com and self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/413062) in GitLab 16.2.
 
 This rule enforces the defined actions and schedules a scan on the provided date/time.
 
diff --git a/doc/user/clusters/agent/troubleshooting.md b/doc/user/clusters/agent/troubleshooting.md
index f1e85a70fb3..eddc6ef3e16 100644
--- a/doc/user/clusters/agent/troubleshooting.md
+++ b/doc/user/clusters/agent/troubleshooting.md
@@ -108,8 +108,7 @@ certificate authority that is unknown to the agent.
 
 To fix this issue, you can present the CA certificate file to the agent
 by [customizing the Helm installation](install/index.md#customize-the-helm-installation).
-Add `--set config.caCert="$(cat ~/path/to/ca.crt)"` to the `helm install` command. Make sure to replace `~/path/to/ca.crt`
-with the path to your internal CA's certificate file. The file should be a valid PEM or DER-encoded certificate.
+Add `--set-file config.caCert=my-custom-ca.pem` to the `helm install` command. The file should be a valid PEM or DER-encoded certificate.
 
 When you deploy `agentk` with a set `config.caCert` value, the certificate is added to `configmap` and the certificate file is mounted in `/etc/ssl/certs`.
 
diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md
index 5f0c6804d76..1c6dd4ad7f6 100644
--- a/doc/user/group/import/index.md
+++ b/doc/user/group/import/index.md
@@ -66,6 +66,8 @@ transfer.
 
 ### Limits
 
+Hardcoded limits apply on migration by direct transfer.
+
 | Limit       | Description                                                                                                                                                                     |
 |:------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | 6           | Maximum number of migrations permitted by a destination GitLab instance per minute per user. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386452) in GitLab 15.9. |
diff --git a/doc/user/project/ml/experiment_tracking/index.md b/doc/user/project/ml/experiment_tracking/index.md
index 936a89260d8..b2ca8a6df1a 100644
--- a/doc/user/project/ml/experiment_tracking/index.md
+++ b/doc/user/project/ml/experiment_tracking/index.md
@@ -6,10 +6,8 @@ info: Machine Learning Experiment Tracking is a GitLab Incubation Engineering pr
 
 # Machine learning model experiments **(FREE)**
 
-FLAG:
-On self-managed GitLab, model experiment tracking is disabled by default.
-To enable the feature, ask an administrator to [enable the feature flag](../../../../administration/feature_flags.md) named `ml_experiment_tracking`.
-On GitLab.com, this feature is enabled on all projects.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/9341) in GitLab 15.11 as an [Experiment](../../../../policy/experiment-beta-support.md#experiment) release [with a flag](../../../../administration/feature_flags.md) named `ml_experiment_tracking`. Disabled by default. To enable the feature, ask an administrator to [enable the feature flag](../../../../administration/feature_flags.md) named `ml_experiment_tracking`.
+> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95373) in GitLab 16.2.
 
 NOTE:
 Model experiment tracking is an [experimental feature](../../../../policy/experiment-beta-support.md). Refer to <https://gitlab.com/gitlab-org/gitlab/-/issues/381660> for feedback and feature requests.
diff --git a/jest.config.base.js b/jest.config.base.js
index 88ccee4d201..1907b084fb6 100644
--- a/jest.config.base.js
+++ b/jest.config.base.js
@@ -30,6 +30,7 @@ module.exports = (path, options = {}) => {
       '^@gitlab/ui/dist/([^.]*)$': [
         '<rootDir>/node_modules/@gitlab/ui/src/$1.vue',
         '<rootDir>/node_modules/@gitlab/ui/src/$1.js',
+        '<rootDir>/node_modules/@gitlab/ui/dist/$1.js',
       ],
       '^@gitlab/ui$': '<rootDir>/node_modules/@gitlab/ui/src/index.js',
     });
diff --git a/lib/gitlab/git/repository.rb b/lib/gitlab/git/repository.rb
index e830fab3623..71be986882c 100644
--- a/lib/gitlab/git/repository.rb
+++ b/lib/gitlab/git/repository.rb
@@ -406,20 +406,13 @@ module Gitlab
         return [] if newrevs.empty?
 
         newrevs = newrevs.uniq.sort
-        if Feature.enabled?(:fix_new_blobs_memoization, container)
-          @new_blobs ||= {}
-          @new_blobs[newrevs] ||= blobs(
-            ['--not', '--all', '--not'] + newrevs,
-            with_paths: true,
-            dynamic_timeout: dynamic_timeout
-          ).to_a
-        else
-          @new_blobs ||= Hash.new do |h, revs|
-            h[revs] = blobs(['--not', '--all', '--not'] + newrevs, with_paths: true, dynamic_timeout: dynamic_timeout)
-          end
 
-          @new_blobs[newrevs]
-        end
+        @new_blobs ||= {}
+        @new_blobs[newrevs] ||= blobs(
+          ['--not', '--all', '--not'] + newrevs,
+          with_paths: true,
+          dynamic_timeout: dynamic_timeout
+        ).to_a
       end
 
       # List blobs reachable via a set of revisions. Supports the
diff --git a/spec/features/clusters/create_agent_spec.rb b/spec/features/clusters/create_agent_spec.rb
index 93a49151978..d90c43f452c 100644
--- a/spec/features/clusters/create_agent_spec.rb
+++ b/spec/features/clusters/create_agent_spec.rb
@@ -27,7 +27,8 @@ RSpec.describe 'Cluster agent registration', :js, feature_category: :deployment_
   end
 
   it 'allows the user to select an agent to install, and displays the resulting agent token' do
-    click_button('Connect a cluster')
+    find('[data-testid="clusters-default-action-button"]').click
+
     expect(page).to have_content('Register')
 
     click_button('Select an agent or enter a name to create new')
diff --git a/spec/features/projects/clusters/gcp_spec.rb b/spec/features/projects/clusters/gcp_spec.rb
index f9195904ea3..eadcc0e62c4 100644
--- a/spec/features/projects/clusters/gcp_spec.rb
+++ b/spec/features/projects/clusters/gcp_spec.rb
@@ -54,7 +54,7 @@ RSpec.describe 'Gcp Cluster', :js, feature_category: :deployment_management do
         before do
           visit project_clusters_path(project)
 
-          click_button(class: 'dropdown-toggle-split')
+          click_button(class: 'gl-new-dropdown-toggle')
           click_link 'Connect a cluster (certificate - deprecated)'
         end
 
diff --git a/spec/features/projects/clusters/user_spec.rb b/spec/features/projects/clusters/user_spec.rb
index eb2601bb85f..6da8eea687e 100644
--- a/spec/features/projects/clusters/user_spec.rb
+++ b/spec/features/projects/clusters/user_spec.rb
@@ -25,7 +25,7 @@ RSpec.describe 'User Cluster', :js, feature_category: :deployment_management do
     before do
       visit project_clusters_path(project)
 
-      click_button(class: 'dropdown-toggle-split')
+      click_button(class: 'gl-new-dropdown-toggle')
       click_link 'Connect a cluster (certificate - deprecated)'
     end
 
diff --git a/spec/features/projects/clusters_spec.rb b/spec/features/projects/clusters_spec.rb
index e2737d62749..d40f929d0b2 100644
--- a/spec/features/projects/clusters_spec.rb
+++ b/spec/features/projects/clusters_spec.rb
@@ -125,12 +125,12 @@ RSpec.describe 'Clusters', :js, feature_category: :groups_and_projects do
   def visit_create_cluster_page
     visit project_clusters_path(project)
 
-    click_button(class: 'dropdown-toggle-split')
+    click_button(class: 'gl-new-dropdown-toggle')
     click_link 'Create a cluster'
   end
 
   def visit_connect_cluster_page
-    click_button(class: 'dropdown-toggle-split')
+    click_button(class: 'gl-new-dropdown-toggle')
     click_link 'Connect a cluster (certificate - deprecated)'
   end
 end
diff --git a/spec/frontend/clusters_list/components/clusters_actions_spec.js b/spec/frontend/clusters_list/components/clusters_actions_spec.js
index e4e1986f705..6957862dc2b 100644
--- a/spec/frontend/clusters_list/components/clusters_actions_spec.js
+++ b/spec/frontend/clusters_list/components/clusters_actions_spec.js
@@ -1,4 +1,10 @@
-import { GlButton, GlDropdown, GlDropdownItem, GlTooltip } from '@gitlab/ui';
+import {
+  GlButton,
+  GlDisclosureDropdown,
+  GlDisclosureDropdownItem,
+  GlTooltip,
+  GlButtonGroup,
+} from '@gitlab/ui';
 import { shallowMountExtended } from 'helpers/vue_test_utils_helper';
 import ClustersActions from '~/clusters_list/components/clusters_actions.vue';
 import { createMockDirective, getBinding } from 'helpers/vue_mock_directive';
@@ -18,12 +24,13 @@ describe('ClustersActionsComponent', () => {
     certificateBasedClustersEnabled: true,
   };
 
+  const findButtonGroup = () => wrapper.findComponent(GlButtonGroup);
   const findButton = () => wrapper.findComponent(GlButton);
-  const findDropdown = () => wrapper.findComponent(GlDropdown);
-  const findDropdownItems = () => wrapper.findAllComponents(GlDropdownItem);
+  const findDropdown = () => wrapper.findComponent(GlDisclosureDropdown);
+  const findDropdownItems = () => wrapper.findAllComponents(GlDisclosureDropdownItem);
   const findTooltip = () => wrapper.findComponent(GlTooltip);
   const findDropdownItemIds = () =>
-    findDropdownItems().wrappers.map((x) => x.attributes('data-testid'));
+    findDropdownItems().wrappers.map((x) => x.find('a').attributes('data-testid'));
   const findDropdownItemTexts = () => findDropdownItems().wrappers.map((x) => x.text());
   const findNewClusterDocsLink = () => wrapper.findByTestId('create-cluster-link');
   const findConnectClusterLink = () => wrapper.findByTestId('connect-cluster-link');
@@ -34,6 +41,10 @@ describe('ClustersActionsComponent', () => {
         ...defaultProvide,
         ...provideData,
       },
+      stubs: {
+        GlDisclosureDropdown,
+        GlDisclosureDropdownItem,
+      },
       directives: {
         GlModalDirective: createMockDirective('gl-modal-directive'),
       },
@@ -45,25 +56,23 @@ describe('ClustersActionsComponent', () => {
   });
 
   describe('when the certificate based clusters are enabled', () => {
-    it('renders actions menu', () => {
+    it('renders actions menu button group with dropdown', () => {
+      expect(findButtonGroup().exists()).toBe(true);
+      expect(findButton().exists()).toBe(true);
       expect(findDropdown().exists()).toBe(true);
     });
 
-    it('shows split button in dropdown', () => {
-      expect(findDropdown().props('split')).toBe(true);
-    });
-
     it("doesn't show the tooltip", () => {
       expect(findTooltip().exists()).toBe(false);
     });
 
     describe('when on project level', () => {
       it(`displays default action as ${CLUSTERS_ACTIONS.connectWithAgent}`, () => {
-        expect(findDropdown().props('text')).toBe(CLUSTERS_ACTIONS.connectWithAgent);
+        expect(findButton().text()).toBe(CLUSTERS_ACTIONS.connectWithAgent);
       });
 
       it('renders correct modal id for the default action', () => {
-        const binding = getBinding(findDropdown().element, 'gl-modal-directive');
+        const binding = getBinding(findButton().element, 'gl-modal-directive');
 
         expect(binding.value).toBe(INSTALL_AGENT_MODAL_ID);
       });
@@ -91,6 +100,7 @@ describe('ClustersActionsComponent', () => {
 
         it('disables dropdown', () => {
           expect(findDropdown().props('disabled')).toBe(true);
+          expect(findButton().props('disabled')).toBe(true);
         });
 
         it('shows tooltip explaining why dropdown is disabled', () => {
@@ -98,7 +108,7 @@ describe('ClustersActionsComponent', () => {
         });
 
         it('does not bind split dropdown button', () => {
-          const binding = getBinding(findDropdown().element, 'gl-modal-directive');
+          const binding = getBinding(findButton().element, 'gl-modal-directive');
 
           expect(binding.value).toBe(false);
         });
@@ -148,11 +158,11 @@ describe('ClustersActionsComponent', () => {
     });
 
     it(`displays default action as ${CLUSTERS_ACTIONS.connectCluster}`, () => {
-      expect(findDropdown().props('text')).toBe(CLUSTERS_ACTIONS.connectCluster);
+      expect(findButton().text()).toBe(CLUSTERS_ACTIONS.connectCluster);
     });
 
     it('renders correct modal id for the default action', () => {
-      const binding = getBinding(findDropdown().element, 'gl-modal-directive');
+      const binding = getBinding(findButton().element, 'gl-modal-directive');
 
       expect(binding.value).toBe(INSTALL_AGENT_MODAL_ID);
     });
diff --git a/spec/lib/gitlab/git/repository_spec.rb b/spec/lib/gitlab/git/repository_spec.rb
index feaef8015f2..9ce8a674146 100644
--- a/spec/lib/gitlab/git/repository_spec.rb
+++ b/spec/lib/gitlab/git/repository_spec.rb
@@ -1176,44 +1176,25 @@ RSpec.describe Gitlab::Git::Repository, feature_category: :source_code_managemen
     subject { repository.new_blobs(newrevs) }
 
     describe 'memoization' do
-      context 'when the fix_new_blobs_memoization feature flag is disabled' do
-        before do
-          stub_feature_flags(fix_new_blobs_memoization: false)
-        end
+      before do
+        allow(repository).to receive(:blobs).once.with(["--not", "--all", "--not", "revision1"], kind_of(Hash))
+          .and_return(['first result'])
+        repository.new_blobs(['revision1'])
+      end
 
-        context 'when called with different revisions' do
-          it 'calls blobs with the same arguments and memoizes the result' do # for documenting bug behaviour
-            expect(repository).to receive(:blobs).twice.with(["--not", "--all", "--not", "revision1"], kind_of(Hash))
-              .and_return(['first_result'], ['second_result'])
-            expect(repository.new_blobs(['revision1'])).to eq(['first_result'])
-            expect(repository.new_blobs(['revision2'])).to eq(['second_result'])
-            expect(repository.new_blobs(['revision1'])).to eq(['first_result'])
-            expect(repository.new_blobs(['revision2'])).to eq(['second_result'])
-          end
-        end
+      it 'calls blobs only once' do
+        expect(repository.new_blobs(['revision1'])).to eq(['first result'])
       end
 
-      context 'when the fix_new_blobs_memoization feature flag is enabled' do
+      context 'when called with a different revision' do
         before do
-          allow(repository).to receive(:blobs).once.with(["--not", "--all", "--not", "revision1"], kind_of(Hash))
-            .and_return(['first result'])
-          repository.new_blobs(['revision1'])
+          allow(repository).to receive(:blobs).once.with(["--not", "--all", "--not", "revision2"], kind_of(Hash))
+            .and_return(['second result'])
+          repository.new_blobs(['revision2'])
         end
 
-        it 'calls blobs only once' do
-          expect(repository.new_blobs(['revision1'])).to eq(['first result'])
-        end
-
-        context 'when called with a different revision' do
-          before do
-            allow(repository).to receive(:blobs).once.with(["--not", "--all", "--not", "revision2"], kind_of(Hash))
-              .and_return(['second result'])
-            repository.new_blobs(['revision2'])
-          end
-
-          it 'memoizes the different arguments' do
-            expect(repository.new_blobs(['revision2'])).to eq(['second result'])
-          end
+        it 'memoizes the different arguments' do
+          expect(repository.new_blobs(['revision2'])).to eq(['second result'])
         end
       end
     end
diff --git a/spec/models/merge_request_spec.rb b/spec/models/merge_request_spec.rb
index 6dd962326d3..bf71d289105 100644
--- a/spec/models/merge_request_spec.rb
+++ b/spec/models/merge_request_spec.rb
@@ -3259,6 +3259,20 @@ RSpec.describe MergeRequest, factory_default: :keep, feature_category: :code_rev
     end
   end
 
+  describe '#skipped_mergeable_checks' do
+    subject { build_stubbed(:merge_request).skipped_mergeable_checks(options) }
+
+    where(:options, :skip_ci_check) do
+      {}                              | false
+      { auto_merge_requested: false } | false
+      { auto_merge_requested: true }  | true
+    end
+
+    with_them do
+      it { is_expected.to include(skip_ci_check: skip_ci_check) }
+    end
+  end
+
   describe '#check_mergeability' do
     let(:mergeability_service) { double }
 
diff --git a/spec/serializers/merge_request_poll_widget_entity_spec.rb b/spec/serializers/merge_request_poll_widget_entity_spec.rb
index 726f35418a1..6b80609c348 100644
--- a/spec/serializers/merge_request_poll_widget_entity_spec.rb
+++ b/spec/serializers/merge_request_poll_widget_entity_spec.rb
@@ -60,7 +60,7 @@ RSpec.describe MergeRequestPollWidgetEntity do
       end
     end
 
-    context 'when head pipeline is running' do
+    context 'when head pipeline is running', unless: Gitlab.ee? do
       before do
         create(:ci_pipeline, :running, project: project, ref: resource.source_branch, sha: resource.diff_head_sha)
         resource.update_head_pipeline
diff --git a/spec/services/auto_merge_service_spec.rb b/spec/services/auto_merge_service_spec.rb
index 94f4b414dca..64473884b13 100644
--- a/spec/services/auto_merge_service_spec.rb
+++ b/spec/services/auto_merge_service_spec.rb
@@ -17,10 +17,11 @@ RSpec.describe AutoMergeService, feature_category: :code_review_workflow do
 
     it 'returns all strategies in preference order' do
       if Gitlab.ee?
-        is_expected.to eq(
-          [AutoMergeService::STRATEGY_MERGE_TRAIN,
+        is_expected.to contain_exactly(
+          AutoMergeService::STRATEGY_MERGE_TRAIN,
            AutoMergeService::STRATEGY_ADD_TO_MERGE_TRAIN_WHEN_PIPELINE_SUCCEEDS,
-           AutoMergeService::STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS])
+           AutoMergeService::STRATEGY_MERGE_WHEN_CHECKS_PASS,
+           AutoMergeService::STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS)
       else
         is_expected.to eq([AutoMergeService::STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS])
       end
@@ -74,11 +75,15 @@ RSpec.describe AutoMergeService, feature_category: :code_review_workflow do
       merge_request.update_head_pipeline
     end
 
-    it 'returns preferred strategy' do
+    it 'returns preferred strategy', if: Gitlab.ee? do
+      is_expected.to eq('merge_when_checks_pass')
+    end
+
+    it 'returns preferred strategy', unless: Gitlab.ee? do
       is_expected.to eq('merge_when_pipeline_succeeds')
     end
 
-    context 'when the head piipeline succeeded' do
+    context 'when the head pipeline succeeded' do
       let(:pipeline_status) { :success }
 
       it 'returns available strategies' do
@@ -142,7 +147,11 @@ RSpec.describe AutoMergeService, feature_category: :code_review_workflow do
     context 'when strategy is not specified' do
       let(:strategy) {}
 
-      it 'chooses the most preferred strategy' do
+      it 'chooses the most preferred strategy', if: Gitlab.ee? do
+        is_expected.to eq(:merge_when_checks_pass)
+      end
+
+      it 'chooses the most preferred strategy', unless: Gitlab.ee? do
         is_expected.to eq(:merge_when_pipeline_succeeds)
       end
     end
diff --git a/spec/services/groups/update_shared_runners_service_spec.rb b/spec/services/groups/update_shared_runners_service_spec.rb
index 964b9cc5fed..00eabb5c875 100644
--- a/spec/services/groups/update_shared_runners_service_spec.rb
+++ b/spec/services/groups/update_shared_runners_service_spec.rb
@@ -67,22 +67,6 @@ RSpec.describe Groups::UpdateSharedRunnersService, feature_category: :groups_and
               .and change { sub_group.shared_runners_enabled }.from(false).to(true)
               .and change { project.shared_runners_enabled }.from(false).to(true)
           end
-
-          context 'when enable_shared_runners_for_descendants feature flag is disabled' do
-            before do
-              stub_feature_flags(enable_shared_runners_for_descendants: false)
-            end
-
-            it 'enables shared Runners only for itself' do
-              expect do
-                expect(subject[:status]).to eq(:success)
-
-                reload_models(group, sub_group, project)
-              end.to change { group.shared_runners_enabled }.from(false).to(true)
-                .and not_change { sub_group.shared_runners_enabled }.from(false)
-                .and not_change { project.shared_runners_enabled }.from(false)
-            end
-          end
         end
 
         context 'when group has pending builds' do
diff --git a/spec/services/merge_requests/merge_orchestration_service_spec.rb b/spec/services/merge_requests/merge_orchestration_service_spec.rb
index 389956bf258..b9bf936eddd 100644
--- a/spec/services/merge_requests/merge_orchestration_service_spec.rb
+++ b/spec/services/merge_requests/merge_orchestration_service_spec.rb
@@ -45,7 +45,17 @@ RSpec.describe MergeRequests::MergeOrchestrationService, feature_category: :code
           subject
 
           expect(merge_request).to be_auto_merge_enabled
-          expect(merge_request.auto_merge_strategy).to eq(AutoMergeService::STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS)
+
+          if Gitlab.ee?
+            expect(merge_request.auto_merge_strategy).to(
+              eq(AutoMergeService::STRATEGY_MERGE_WHEN_CHECKS_PASS)
+            )
+          else
+            expect(merge_request.auto_merge_strategy).to(
+              eq(AutoMergeService::STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS)
+            )
+          end
+
           expect(merge_request).not_to be_merged
         end
       end
@@ -108,7 +118,11 @@ RSpec.describe MergeRequests::MergeOrchestrationService, feature_category: :code
         merge_request.update_head_pipeline
       end
 
-      it 'fetches perferred auto merge strategy' do
+      it 'fetches preferred auto merge strategy', if: Gitlab.ee? do
+        is_expected.to eq(AutoMergeService::STRATEGY_MERGE_WHEN_CHECKS_PASS)
+      end
+
+      it 'fetches preferred auto merge strategy', unless: Gitlab.ee? do
         is_expected.to eq(AutoMergeService::STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS)
       end
     end
diff --git a/spec/services/merge_requests/update_service_spec.rb b/spec/services/merge_requests/update_service_spec.rb
index 09e13ffb91f..79f608a4614 100644
--- a/spec/services/merge_requests/update_service_spec.rb
+++ b/spec/services/merge_requests/update_service_spec.rb
@@ -552,7 +552,8 @@ RSpec.describe MergeRequests::UpdateService, :mailer, feature_category: :code_re
             head_pipeline_of: merge_request
           )
 
-          expect(AutoMerge::MergeWhenPipelineSucceedsService).to receive(:new).with(project, user, { sha: merge_request.diff_head_sha })
+          strategies_count = Gitlab.ee? ? :twice : :once
+          expect(AutoMerge::MergeWhenPipelineSucceedsService).to receive(:new).exactly(strategies_count).with(project, user, { sha: merge_request.diff_head_sha })
             .and_return(service_mock)
           allow(service_mock).to receive(:available_for?) { true }
           expect(service_mock).to receive(:execute).with(merge_request)
diff --git a/spec/services/quick_actions/interpret_service_spec.rb b/spec/services/quick_actions/interpret_service_spec.rb
index 06ccb9fe42e..186b532233e 100644
--- a/spec/services/quick_actions/interpret_service_spec.rb
+++ b/spec/services/quick_actions/interpret_service_spec.rb
@@ -539,7 +539,12 @@ RSpec.describe QuickActions::InterpretService, feature_category: :team_planning
         _, updates, message = service.execute(content, issuable)
 
         expect(updates).to eq(merge: merge_request.diff_head_sha)
-        expect(message).to eq('Scheduled to merge this merge request (Merge when pipeline succeeds).')
+
+        if Gitlab.ee?
+          expect(message).to eq('Scheduled to merge this merge request (Merge when checks pass).')
+        else
+          expect(message).to eq('Scheduled to merge this merge request (Merge when pipeline succeeds).')
+        end
       end
     end
 
diff --git a/spec/support/shared_examples/quick_actions/merge_request/merge_quick_action_shared_examples.rb b/spec/support/shared_examples/quick_actions/merge_request/merge_quick_action_shared_examples.rb
index acbc6429646..cf5a67f6096 100644
--- a/spec/support/shared_examples/quick_actions/merge_request/merge_quick_action_shared_examples.rb
+++ b/spec/support/shared_examples/quick_actions/merge_request/merge_quick_action_shared_examples.rb
@@ -41,7 +41,13 @@ RSpec.shared_examples 'merge quick action' do
         it 'schedules to merge the MR' do
           add_note("/merge")
 
-          expect(page).to have_content "Scheduled to merge this merge request (Merge when pipeline succeeds)."
+          if Gitlab.ee?
+            expect(page).to(
+              have_content("Scheduled to merge this merge request (Merge when checks pass).")
+            )
+          else
+            expect(page).to have_content "Scheduled to merge this merge request (Merge when pipeline succeeds)."
+          end
 
           expect(merge_request.reload).to be_auto_merge_enabled
           expect(merge_request.reload).not_to be_merged