Add latest changes from gitlab-org/gitlab@master

2023-07-18 00:08:30 +00:00 · 2023-07-18 00:08:30 +00:00 · ccceee2174
parent 9c2ea77514
commit ccceee2174
48 changed files with 657 additions and 418 deletions
--- 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>
--- 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

--- 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?
--- 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(
--- 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 },
--- 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 }
--- 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
--- a/config/feature_flags/development/enable_shared_runners_for_descendants.yml
+++ b/config/feature_flags/development/enable_shared_runners_for_descendants.yml
@ -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
--- a/config/feature_flags/development/fix_new_blobs_memoization.yml
+++ b/config/feature_flags/development/fix_new_blobs_memoization.yml
@ -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
--- 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
--- 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'] ||= {}
--- 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',
  });
--- a/db/migrate/20230620101808_change_default_value_for_distro_version.rb
+++ 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
--- 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,
--- a/db/schema_migrations/20230620101808
+++ b/db/schema_migrations/20230620101808
@ -0,0 +1 @@
+8c797f079ce4536559bbe73b9c18540f5793dc725eb970ac23bfeb1578f8adc2
--- 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[],
--- 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.
--- 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
    }
  }
--- a/doc/administration/settings/usage_statistics.md
+++ 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. -->
--- 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`
--- 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
--- a/doc/development/avoiding_required_stops.md
+++ 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)
--- 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:
--- 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)
--- 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

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

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

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

--- 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`.

--- 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. |
--- 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.
--- 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',
    });
--- 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
--- 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')
--- 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

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

--- 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
--- 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);
    });
--- 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
-
-        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
+      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 the fix_new_blobs_memoization feature flag is enabled' do
+      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", "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
--- 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 }

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

--- 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
				`@ -0,0 +1 @@`
				`8c797f079ce4536559bbe73b9c18540f5793dc725eb970ac23bfeb1578f8adc2`