Add latest changes from gitlab-org/gitlab@master

2025-02-13 00:12:13 +00:00 · 2025-02-13 00:12:13 +00:00 · 9bb15d0553
parent a26438c547
commit 9bb15d0553
89 changed files with 918 additions and 369 deletions
--- a/.rubocop.yml
+++ b/.rubocop.yml
@ -11,7 +11,6 @@ inherit_from:
    <% Dir.glob('.rubocop_todo/**/*.yml').each do |rubocop_todo_yaml| %>
  - '<%= rubocop_todo_yaml %>'
    <% end %>
-  - '.rubocop_todo.yml'
  <% end %>
  - ./rubocop/rubocop-migrations.yml
  - ./rubocop/rubocop-usage-data.yml
--- a/.rubocop_todo.yml
+++ b/.rubocop_todo.yml
@ -1,7 +0,0 @@
-# This configuration is no longer used.
-#
-# The RuboCop TODO lists are located in `.rubocop_todo/**/*.yml`.
-#
-# Please use `rake rubocop:todo:generate` to generate TODOs.
-#
-# See https://docs.gitlab.com/ee/development/rake_tasks.html#generate-initial-rubocop-todo-list
--- a/.rubocop_todo/rspec/be_eq.yml
+++ b/.rubocop_todo/rspec/be_eq.yml
@ -267,7 +267,6 @@ RSpec/BeEq:
    - 'ee/spec/models/namespaces/combined_storage_users/pre_enforcement_spec.rb'
    - 'ee/spec/models/namespaces/free_user_cap/enforcement_without_storage_spec.rb'
    - 'ee/spec/models/namespaces/free_user_cap/root_size_spec.rb'
-    - 'ee/spec/models/namespaces/storage/enforcement_spec.rb'
    - 'ee/spec/models/namespaces/storage/root_size_spec.rb'
    - 'ee/spec/models/onboarding/completion_spec.rb'
    - 'ee/spec/models/onboarding/progress_spec.rb'
--- a/.rubocop_todo/rspec/receive_messages.yml
+++ b/.rubocop_todo/rspec/receive_messages.yml
@ -99,7 +99,6 @@ RSpec/ReceiveMessages:
    - 'ee/spec/models/merge_request_spec.rb'
    - 'ee/spec/models/merge_trains/train_spec.rb'
    - 'ee/spec/models/namespace_setting_spec.rb'
-    - 'ee/spec/models/namespaces/storage/enforcement_spec.rb'
    - 'ee/spec/models/project_feature_spec.rb'
    - 'ee/spec/models/security/scan_result_policy_read_spec.rb'
    - 'ee/spec/policies/issue_policy_spec.rb'
--- a/app/assets/javascripts/pages/groups/new/components/app.vue
+++ b/app/assets/javascripts/pages/groups/new/components/app.vue
@ -1,4 +1,6 @@
 <script>
+import GROUP_IMPORT_SVG_URL from '@gitlab/svgs/dist/illustrations/group-import.svg?url';
+import GROUP_NEW_SVG_URL from '@gitlab/svgs/dist/illustrations/group-new.svg?url';
 import { s__ } from '~/locale';
 import NewNamespacePage from '~/vue_shared/new_namespace/new_namespace_page.vue';
 import createGroupDescriptionDetails from './create_group_description_details.vue';
@ -71,6 +73,7 @@ export default {
            parentGroupName: this.parentGroupName,
            importExistingGroupPath: this.importExistingGroupPath,
          },
+          imageSrc: GROUP_NEW_SVG_URL,
        },
        {
          name: 'import-group-pane',
@ -80,6 +83,7 @@ export default {
            'GroupsNew|Import a group and related data from another GitLab instance.',
          ),
          details: 'Migrate your existing groups from another instance of GitLab.',
+          imageSrc: GROUP_IMPORT_SVG_URL,
        },
      ];
    },
--- a/app/assets/javascripts/projects/new/components/app.vue
+++ b/app/assets/javascripts/projects/new/components/app.vue
@ -1,4 +1,8 @@
 <script>
+import PROJECT_CREATE_FROM_TEMPLATE_SVG_URL from '@gitlab/svgs/dist/illustrations/project-create-from-template-sm.svg?url';
+import PROJECT_CREATE_NEW_SVG_URL from '@gitlab/svgs/dist/illustrations/project-create-new-sm.svg?url';
+import PROJECT_IMPORT_SVG_URL from '@gitlab/svgs/dist/illustrations/project-import-sm.svg?url';
+import PROJECT_RUN_CICD_PIPELINES_SVG_URL from '@gitlab/svgs/dist/illustrations/empty-state/empty-devops-md.svg?url';
 import SafeHtml from '~/vue_shared/directives/safe_html';
 import { s__ } from '~/locale';
 import NewNamespacePage from '~/vue_shared/new_namespace/new_namespace_page.vue';
@ -15,6 +19,7 @@ const PANELS = [
    description: s__(
      'ProjectsNew|Create a blank project to store your files, plan your work, and collaborate on code, among other things.',
    ),
+    imageSrc: PROJECT_CREATE_NEW_SVG_URL,
  },
  {
    key: 'template',
@ -24,6 +29,7 @@ const PANELS = [
    description: s__(
      'ProjectsNew|Create a project pre-populated with the necessary files to get you started quickly.',
    ),
+    imageSrc: PROJECT_CREATE_FROM_TEMPLATE_SVG_URL,
  },
  {
    key: 'import',
@ -33,6 +39,7 @@ const PANELS = [
    description: s__(
      'ProjectsNew|Migrate your data from an external source like GitHub, Bitbucket, or another instance of GitLab.',
    ),
+    imageSrc: PROJECT_IMPORT_SVG_URL,
  },
  {
    key: 'ci',
@ -40,6 +47,7 @@ const PANELS = [
    selector: '#ci-cd-project-pane',
    title: s__('ProjectsNew|Run CI/CD for external repository'),
    description: s__('ProjectsNew|Connect your external repository to GitLab CI/CD.'),
+    imageSrc: PROJECT_RUN_CICD_PIPELINES_SVG_URL,
  },
 ];

--- a/app/assets/javascripts/work_items/components/design_management/design_item.vue
+++ b/app/assets/javascripts/work_items/components/design_management/design_item.vue
@ -60,6 +60,14 @@ export default {
      required: false,
      default: false,
    },
+    useRouter: {
+      type: Boolean,
+      required: true,
+    },
+    workItemWebUrl: {
+      type: String,
+      required: true,
+    },
  },
  data() {
    return {
@ -113,6 +121,12 @@ export default {
        query: this.$route.query,
      };
    },
+    nonRouterHref() {
+      return `${this.workItemWebUrl}/designs/${this.filename}`;
+    },
+    linkComponent() {
+      return this.useRouter ? 'router-link' : 'a';
+    },
  },
  methods: {
    onImageLoad() {
@ -144,8 +158,10 @@ export default {
 </script>

 <template>
-  <router-link
+  <component
+    :is="linkComponent"
    :to="routerLinkProps"
+    :href="nonRouterHref"
    class="card js-design-list-item design-list-item gl-mb-0 gl-cursor-pointer gl-text-default hover:gl-text-default"
  >
    <div
@ -206,5 +222,5 @@ export default {
        </span>
      </div>
    </div>
-  </router-link>
+  </component>
 </template>
--- a/app/assets/javascripts/work_items/components/design_management/design_management_widget.vue
+++ b/app/assets/javascripts/work_items/components/design_management/design_management_widget.vue
@ -4,10 +4,11 @@ import { GlBreakpointInstance } from '@gitlab/ui/dist/utils';
 import VueDraggable from 'vuedraggable';
 import * as Sentry from '~/sentry/sentry_browser_wrapper';
 import { s__ } from '~/locale';
+import glFeatureFlagMixin from '~/vue_shared/mixins/gl_feature_flags_mixin';
 import { isLoggedIn } from '~/lib/utils/common_utils';
 import { TYPENAME_DESIGN_VERSION } from '~/graphql_shared/constants';
 import { convertToGraphQLId } from '~/graphql_shared/utils';
-import { findDesignWidget } from '~/work_items/utils';
+import { findDesignWidget, canRouterNav } from '~/work_items/utils';
 import CrudComponent from '~/vue_shared/components/crud_component.vue';
 import DesignDropzone from '~/vue_shared/components/upload_dropzone/upload_dropzone.vue';
 import {
@ -42,6 +43,7 @@ export default {
  directives: {
    GlTooltip: GlTooltipDirective,
  },
+  mixins: [glFeatureFlagMixin()],
  inject: ['fullPath'],
  props: {
    workItemId: {
@ -74,6 +76,18 @@ export default {
      required: false,
      default: false,
    },
+    workItemFullPath: {
+      type: String,
+      required: true,
+    },
+    workItemWebUrl: {
+      type: String,
+      required: true,
+    },
+    isGroup: {
+      type: Boolean,
+      required: true,
+    },
  },
  apollo: {
    designCollection: {
@ -190,6 +204,21 @@ export default {
        ? s__('DesignManagement|Deselect all')
        : s__('DesignManagement|Select all');
    },
+    issueAsWorkItem() {
+      return Boolean(
+        !this.isGroup &&
+          this.glFeatures.workItemsViewPreference &&
+          gon.current_user_use_work_items_view,
+      );
+    },
+    canUseRouter() {
+      return canRouterNav({
+        fullPath: this.fullPath,
+        webUrl: this.workItemWebUrl,
+        isGroup: this.isGroup,
+        issueAsWorkItem: this.issueAsWorkItem,
+      });
+    },
  },
  methods: {
    dismissError() {
@ -231,7 +260,7 @@ export default {
          mutation: archiveDesignMutation,
          variables: {
            filenames: this.selectedDesigns,
-            projectPath: this.fullPath,
+            projectPath: this.workItemFullPath,
            iid: this.workItemIid,
          },
          update: this.afterArchiveDesign,
@ -471,6 +500,8 @@ export default {
                :is-uploading="false"
                :is-dragging="isDraggingDesign"
                :work-item-iid="workItemIid"
+                :work-item-web-url="workItemWebUrl"
+                :use-router="canUseRouter"
                data-testid="design-item"
                @pointerup="onPointerUp"
              />
--- a/app/assets/javascripts/work_items/components/work_item_detail.vue
+++ b/app/assets/javascripts/work_items/components/work_item_detail.vue
@ -1029,6 +1029,9 @@ export default {
              :class="{ 'gl-mt-0': isDrawer }"
              :work-item-id="workItem.id"
              :work-item-iid="iid"
+              :work-item-full-path="workItemFullPath"
+              :work-item-web-url="workItem.webUrl"
+              :is-group="isGroupWorkItem"
              :upload-error="designUploadError"
              :upload-error-variant="designUploadErrorVariant"
              :is-saving="isSaving"
--- a/app/helpers/issuables_helper.rb
+++ b/app/helpers/issuables_helper.rb
@ -206,14 +206,6 @@ module IssuablesHelper
    finder.class.scalar_params.any? { |p| params[p].present? }
  end

-  def issuable_squash_option?(issuable, project)
-    if issuable.persisted?
-      issuable.squash
-    else
-      project.squash_enabled_by_default?
-    end
-  end
-
  def issuable_type_selector_data(issuable)
    {
      selected_type: issuable.issue_type,
--- a/app/helpers/merge_requests_helper.rb
+++ b/app/helpers/merge_requests_helper.rb
@ -363,6 +363,10 @@ module MergeRequestsHelper
      show_new_mr_dashboard_banner?
  end

+  def merge_request_squash_option?(merge_request)
+    merge_request.persisted? ? merge_request.squash : merge_request.squash_enabled_by_default?
+  end
+
  private

  def review_requested_merge_requests_count
--- a/app/models/concerns/encrypted_user_password.rb
+++ b/app/models/concerns/encrypted_user_password.rb
@ -12,6 +12,16 @@ module EncryptedUserPassword
  BCRYPT_STRATEGY = :bcrypt
  PBKDF2_SHA512_STRATEGY = :pbkdf2_sha512

+  class_methods do
+    def stretches
+      prior_stretches = Rails.env.test? ? 1 : 10
+
+      return prior_stretches unless Feature.enabled?(:increase_password_storage_stretches) # rubocop:disable Gitlab/FeatureFlagWithoutActor -- required to enable FFing a Class method, which is required to FF the Stretches config
+
+      Rails.env.test? ? 5 : 13
+    end
+  end
+
  # Use Devise DatabaseAuthenticatable#authenticatable_salt
  # unless encrypted password is PBKDF2+SHA512.
  def authenticatable_salt
@ -69,11 +79,27 @@ module EncryptedUserPassword
  end

  def migrate_password!(password)
-    return true if password_strategy == encryptor
+    # A note on ordering here:
+    # Other code expects to use this function to switch between pbkdf2 and bcrypt.
+    # Hence, if password strategy != encryptor, we need to fail immediately and migrate.
+    # Reversing this ordering will break tests in spec/models/concerns/encrypted_user_password_spec.rb.
+
+    if password_strategy == encryptor
+      return true unless Feature.enabled?(:increase_password_storage_stretches) # rubocop:disable Gitlab/FeatureFlagWithoutActor -- required to enable FFing a Class method, which is required to FF the Stretches config
+      return true if (BCRYPT_STRATEGY == password_strategy) && bcrypt_password_matches_current_stretches?
+      # We do not attempt to upgrade stretches on PBKDF2-stored passwords.
+      return true if PBKDF2_SHA512_STRATEGY == password_strategy
+    end

    update_attribute(:password, password)
  end

+  def bcrypt_password_matches_current_stretches?
+    return false unless bcrypt_password?
+
+    ::BCrypt::Password.new(encrypted_password).cost == self.class.stretches
+  end
+
  def encryptor
    return BCRYPT_STRATEGY unless Gitlab::FIPS.enabled?

--- a/app/services/users/reset_incoming_email_token_service.rb
+++ b/app/services/users/reset_incoming_email_token_service.rb
@ -0,0 +1,26 @@
+# frozen_string_literal: true
+
+module Users
+  class ResetIncomingEmailTokenService < BaseService
+    def initialize(current_user:, user:)
+      @current_user = current_user
+      @user = user
+    end
+
+    def execute!
+      return ServiceResponse.error(message: s_('Not permitted to reset user feed token')) unless reset_permitted?
+
+      Users::UpdateService.new(current_user, user: user).execute!(&:reset_incoming_email_token!)
+
+      ServiceResponse.success(message: 'Incoming mail token was successfully reset')
+    end
+
+    private
+
+    attr_reader :user
+
+    def reset_permitted?
+      Ability.allowed?(current_user, :update_user, user)
+    end
+  end
+end
--- a/app/views/shared/issuable/form/_merge_params.html.haml
+++ b/app/views/shared/issuable/form/_merge_params.html.haml
@ -1,33 +1,35 @@
- issuable = local_assigns.fetch(:issuable)
- project = local_assigns.fetch(:project)
+- merge_request = local_assigns.fetch(:issuable)

- return unless issuable.is_a?(MergeRequest)
- return if issuable.closed_or_merged_without_fork?
+- return if !merge_request.is_a?(MergeRequest) || merge_request.closed_or_merged_without_fork?

 .form-group.row.gl-mb-7
  .col-12
    %label
      = _('Merge options')
-    - if issuable.can_remove_source_branch?(current_user)
+    - if merge_request.can_remove_source_branch?(current_user)
      .form-check.gl-pl-0
        = hidden_field_tag 'merge_request[force_remove_source_branch]', '0', id: nil
-        = render Pajamas::CheckboxTagComponent.new(name: 'merge_request[force_remove_source_branch]', checked: issuable.force_remove_source_branch?, value: '1', checkbox_options: { class: 'js-form-update' }) do |c|
+        = render Pajamas::CheckboxTagComponent.new(name: 'merge_request[force_remove_source_branch]', checked: merge_request.force_remove_source_branch?, value: '1', checkbox_options: { class: 'js-form-update' }) do |c|
          - c.with_label do
            = _("Delete source branch when merge request is accepted.")

-    - if !project.squash_never?
+    - unless merge_request.squash_never?
      .form-check.gl-pl-0
-        - if project.squash_always?
+        - if merge_request.squash_always?
          = hidden_field_tag 'merge_request[squash]', '1', id: nil
-          = render Pajamas::CheckboxTagComponent.new(name: 'merge_request[squash]', checked: project.squash_enabled_by_default?, value: '1', checkbox_options: { class: 'js-form-update', disabled: true }) do |c|
+          = render Pajamas::CheckboxTagComponent.new(name: 'merge_request[squash]', checked: true, value: '1', checkbox_options: { class: 'js-form-update', disabled: true }) do |c|
            - c.with_label do
              = _("Squash commits when merge request is accepted.")
              = link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/squash_and_merge.md'), target: '_blank', rel: 'noopener noreferrer'
            - c.with_help_text do
-              = _('Required in this project.')
+              -# When we remove the feature flag we should also remove the local_assigns[:project]
+              - if Feature.enabled?(:branch_rule_squash_settings, local_assigns.fetch(:project))
+                = _('Required in this branch.')
+              - else
+                = _('Required in this project.')
        - else
          = hidden_field_tag 'merge_request[squash]', '0', id: nil
-          = render Pajamas::CheckboxTagComponent.new(name: 'merge_request[squash]', checked: issuable_squash_option?(issuable, project), value: '1', checkbox_options: { class: 'js-form-update' }) do |c|
+          = render Pajamas::CheckboxTagComponent.new(name: 'merge_request[squash]', checked: merge_request_squash_option?(merge_request), value: '1', checkbox_options: { class: 'js-form-update' }) do |c|
            - c.with_label do
              = _("Squash commits when merge request is accepted.")
              = link_to sprite_icon('question-o'), help_page_path('user/project/merge_requests/squash_and_merge.md'), target: '_blank', rel: 'noopener noreferrer'
--- a/app/workers/pages/reset_pages_default_domain_redirect_worker.rb
+++ b/app/workers/pages/reset_pages_default_domain_redirect_worker.rb
@ -13,7 +13,9 @@ module Pages

      return unless project_settings
      return unless project_settings.pages_primary_domain
-      return unless event.data['domain'] == project_settings.pages_primary_domain
+
+      primary_domain = URI.parse(project_settings.pages_primary_domain).host
+      return unless event.data['domain'] == primary_domain

      project_settings.update!(pages_primary_domain: nil)
    end
--- a/app/workers/repository_update_remote_mirror_worker.rb
+++ b/app/workers/repository_update_remote_mirror_worker.rb
@ -31,7 +31,7 @@ class RepositoryUpdateRemoteMirrorWorker
      ttl: remote_mirror.max_runtime,
      sleep_sec: LOCK_WAIT_TIME
    ) do
-      update_mirror(remote_mirror, scheduled_time, tries)
+      update_mirror(remote_mirror, tries)
    end
  rescue Gitlab::ExclusiveLeaseHelpers::FailedToObtainLockError
    # If an update runs longer than 1.5 minutes, we'll reschedule it
@ -42,13 +42,13 @@ class RepositoryUpdateRemoteMirrorWorker

  private

-  def update_mirror(mirror, scheduled_time, tries)
+  def update_mirror(mirror, tries)
    project = mirror.project
    current_user = project.creator
    result = Projects::UpdateRemoteMirrorService.new(project, current_user).execute(mirror, tries)

    if result[:status] == :error && mirror.to_retry?
-      schedule_retry(mirror, scheduled_time, tries)
+      schedule_retry(mirror, tries)
    end
  end

@ -56,12 +56,8 @@ class RepositoryUpdateRemoteMirrorWorker
    [self.class.name, mirror_id].join(':')
  end

-  def schedule_retry(mirror, scheduled_time, tries)
-    retry_time = if Feature.enabled?(:remote_mirror_retry_with_delay, mirror.project)
-                   Time.current + 1.second
-                 else
-                   scheduled_time
-                 end
+  def schedule_retry(mirror, tries)
+    retry_time = Time.current + 1.second

    self.class.perform_in(mirror.backoff_delay, mirror.id, retry_time, tries + 1)
  end
--- a/config/feature_flags/gitlab_com_derisk/increase_password_storage_stretches.yml
+++ b/config/feature_flags/gitlab_com_derisk/increase_password_storage_stretches.yml
@ -0,0 +1,9 @@
+---
+name: increase_password_storage_stretches
+feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/222481
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/177154
+rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/511397
+milestone: '17.9'
+group: group::authentication
+type: gitlab_com_derisk
+default_enabled: false
--- a/config/feature_flags/gitlab_com_derisk/remote_mirror_retry_with_delay.yml
+++ b/config/feature_flags/gitlab_com_derisk/remote_mirror_retry_with_delay.yml
@ -1,9 +0,0 @@
---
-name: remote_mirror_retry_with_delay
-feature_issue_url: 
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/146707
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/472002
-milestone: '17.3'
-group: group::source code
-type: gitlab_com_derisk
-default_enabled: false
--- a/config/initializers/8_devise.rb
+++ b/config/initializers/8_devise.rb
@ -80,6 +80,13 @@ Devise.setup do |config|
  # Limiting the stretches to just one in testing will increase the performance of
  # your test suite dramatically. However, it is STRONGLY RECOMMENDED to not use
  # a value less than 10 in other environments.
+
+  # The bcrypt gem does not allow stretches to be set less than 4 (it will ignore it).
+  # To allow password WF upgrade testing (spec/models/concerns/encrypted_user_password_spec.rb),
+  # changing the test-side configuration to 5 to give the test something to do,
+  # along with changing the production value to 13 for https://gitlab.com/gitlab-org/gitlab/-/issues/222481.
+  # config.stretches = Rails.env.test? ? 5 : 13
+  # NOTE: This is being overridden in the `encrypted_user_password.rb` concern, behind an FF
  config.stretches = Rails.env.test? ? 1 : 10

  # Set up a pepper to generate the encrypted password.
--- a/config/metrics/counts_28d/20210409100451_users_expanding_testing_code_quality_report_monthly.yml
+++ b/config/metrics/counts_28d/20210409100451_users_expanding_testing_code_quality_report_monthly.yml
@ -2,7 +2,7 @@
 data_category: optional
 key_path: redis_hll_counters.testing.users_expanding_testing_code_quality_report_monthly
 description: Count of expanding the code quality widget
-product_group: dynamic_analysis
+product_group: static_analysis
 product_categories:
 - code_quality
 value_type: number
--- a/config/metrics/counts_28d/20210901221410_p_ci_templates_code_quality_monthly.yml
+++ b/config/metrics/counts_28d/20210901221410_p_ci_templates_code_quality_monthly.yml
@ -1,7 +1,7 @@
 ---
 key_path: redis_hll_counters.ci_templates.p_ci_templates_code_quality_monthly
 description: ''
-product_group: pipeline_authoring
+product_group: static_analysis
 value_type: number
 status: active
 milestone: '14.3'
--- a/config/metrics/counts_28d/20220727020440_i_code_review_merge_request_widget_code_quality_view_monthly.yml
+++ b/config/metrics/counts_28d/20220727020440_i_code_review_merge_request_widget_code_quality_view_monthly.yml
@ -1,7 +1,7 @@
 ---
 key_path: redis_hll_counters.code_review.i_code_review_merge_request_widget_code_quality_view_monthly
 description: The count of unique users (monthly) who were able to see the Code Quality widget extension
-product_group: code_review
+product_group: static_analysis
 product_categories:
 - code_review_workflow
 value_type: number
--- a/config/metrics/counts_7d/20210409100451_users_expanding_testing_code_quality_report_weekly.yml
+++ b/config/metrics/counts_7d/20210409100451_users_expanding_testing_code_quality_report_weekly.yml
@ -2,7 +2,7 @@
 data_category: optional
 key_path: redis_hll_counters.testing.users_expanding_testing_code_quality_report_weekly
 description: Count of expanding the code quality widget
-product_group: dynamic_analysis
+product_group: static_analysis
 product_categories:
 - code_quality
 value_type: number
--- a/config/metrics/counts_7d/20210901221405_p_ci_templates_code_quality_weekly.yml
+++ b/config/metrics/counts_7d/20210901221405_p_ci_templates_code_quality_weekly.yml
@ -1,7 +1,7 @@
 ---
 key_path: redis_hll_counters.ci_templates.p_ci_templates_code_quality_weekly
 description: ''
-product_group: pipeline_authoring
+product_group: static_analysis
 value_type: number
 status: active
 milestone: '14.3'
--- a/data/deprecations/17-9-DS-for-JS-vendored-libraries.yml
+++ b/data/deprecations/17-9-DS-for-JS-vendored-libraries.yml
@ -0,0 +1,42 @@
+- title: "Dependency Scanning for JavaScript vendored libraries"
+  # The milestones for the deprecation announcement, and the removal.
+  removal_milestone: "18.0"
+  announcement_milestone: "17.9"
+  # Change breaking_change to false if needed.
+  breaking_change: true
+  window: 1  # Can be 1, 2, or 3 - The window when the breaking change will be deployed on GitLab.com
+  reporter: gonzoyumo  # The GitLab username of the person reporting the change
+  stage: application_security_testing
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/501308
+  # Use the impact calculator https://gitlab-com.gitlab.io/gl-infra/breaking-change-impact-calculator/?
+  impact: low  # Can be one of: [critical, high, medium, low]
+  scope: project  # Can be one or a combination of: [instance, group, project]
+  resolution_role: Maintainer  # Can be one of: [Admin, Owner, Maintainer, Developer]
+  manual_task: true  # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false).
+  body: |  # (required) Don't change this line.
+    The [Dependency Scanning for JavaScript vendored libraries](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#javascript) feature
+    provided by the Gemnasium analyzer for Dependency Scanning is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+
+    While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+    See details in [the migration guide](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/migration_guide_to_sbom_based_scans.html)
+
+    A replacement feature will be developed with [Dependency Scanning on vendored libraries](https://gitlab.com/groups/gitlab-org/-/epics/7186) but no timeline has been set for its delivery.
+
+# ==============================
+# OPTIONAL END-OF-SUPPORT FIELDS
+# ==============================
+#
+# If an End of Support period applies:
+# 1) Share this announcement in the `#spt_managers` Support channel in Slack
+# 2) Mention `@gitlab-com/support` in this merge request.
+#
+  # When support for this feature ends, in XX.YY milestone format.
+  end_of_support_milestone: 18.0
+  # Array of tiers the feature is currently available to,
+  # like [Free, Silver, Gold, Core, Premium, Ultimate]
+  tiers: Ultimate
+  # Links to documentation and thumbnail image
+  documentation_url: https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#javascript
+  image_url:
+  # Use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  video_url:
--- a/data/deprecations/17-9-DS-upgrade-to-SBOM-scanner.yml
+++ b/data/deprecations/17-9-DS-upgrade-to-SBOM-scanner.yml
@ -0,0 +1,72 @@
+- title: "Dependency Scanning upgrades to the GitLab SBOM Vulnerability Scanner"
+  # The milestones for the deprecation announcement, and the removal.
+  removal_milestone: "18.0"
+  announcement_milestone: "17.9"
+  # Change breaking_change to false if needed.
+  breaking_change: true
+  window: 1  # Can be 1, 2, or 3 - The window when the breaking change will be deployed on GitLab.com
+  reporter: gonzoyumo  # The GitLab username of the person reporting the change
+  stage: application_security_testing
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/501308
+  # Use the impact calculator https://gitlab-com.gitlab.io/gl-infra/breaking-change-impact-calculator/?
+  impact: high
+  scope: project  # Can be one or a combination of: [instance, group, project]
+  resolution_role: Maintainer  # Can be one of: [Admin, Owner, Maintainer, Developer]
+  manual_task: true  # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false).
+  body: |  # (required) Don't change this line.
+    The Dependency Scanning feature is upgrading to the GitLab SBOM Vulnerability Scanner. As part of this change, the Gemnasium analyzer (previously used in CI/CD pipelines) is deprecated in GitLab 17.9
+    and reaches [end of support](https://docs.gitlab.com/ee/update/terminology.html#end-of-support) in GitLab 18.0.
+    It is replaced with the [new Dependency Scanning analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/dependency-scanning) that focuses on detecting dependencies and their relationships (dependency graph).
+    This upgrade represents a fundamental shift: instead of performing security analysis within CI pipelines, the new system uses GitLab's built-in SBOM Vulnerability Scanner, which is already employed by
+    [Continuous Vulnerability Scanning](https://docs.gitlab.com/ee/user/application_security/continuous_vulnerability_scanning/).
+
+    Due to the significant changes and feature removals this upgrade introduces, it will not be implemented automatically. While some breaking changes will take effect in GitLab 18.0, existing CI/CD jobs
+    using the Gemnasium analyzer will continue to function by default to prevent disruption to CI configurations.
+
+    Please review the fully detailed changes below and consult [the migration guide](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/migration_guide_to_sbom_based_scans.html) to assist you with the transition.
+
+    - When using the Dependency Scanning CI/CD template (`Dependency-Scanning.gitlab-ci.yml`), the existing CI/CD jobs based on the Gemnasium analyzer will continue to be used by default. The new Dependency Scanning analyzer will run by default only
+    for newly supported languages and package managers that are not already covered by the Gemnasium analyzer. You can also opt-in to fully migrate to the new Dependency Scanning analyzer and use for all supported projects.
+    - To transition to Dependency Scanning with SBOM, the security scan results generated by the Gemansium analyzer will no longer be uploaded to the GitLab platform as a
+    [Dependency Scanning security report artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdependency_scanning). Instead, Dependency Scanning results will be generated within the GitLab platform,
+    using the GitLab SBOM Vulnerability Scanner, and based on the [CycloneDX SBOM report artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscyclonedx) generated in the CI/CD pipeline.
+    As a result, any workflows that rely on modifying security scan results before uploading them to the GitLab platform will be impacted.
+    However, the Dependency Scanning JSON report will continue to be produced by the Gemnasium analyzer and exported as [a standard job artifact](https://docs.gitlab.com/ee/ci/yaml/index.html#artifactspaths) so that any workflow that consumes this
+    report in a succeeding CI/CD job will continue to work. Please note that further improvements made to the GitLab SBOM Vulnerability Scanner will not be reflected in this JSON report.
+    Since the new Dependency Scanning analyzer does not generate any security report, when migrating users must use the ([`Pipeline.securityReportFindings` resource](https://docs.gitlab.com/ee/api/graphql/reference/index.html#pipelinesecurityreportfindings))
+    of the GraphQL API to programmatically consume security scan results.
+    The ability to [download security scan results via the UI](https://docs.gitlab.com/ee/user/application_security/detect/security_scan_results.html#all-tiers) in this format for the GitLab Dependency Scanning feature is also removed in GitLab 18.0.
+    The [Dependency Scanning security report artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdependency_scanning) itself is not deprecated and GitLab will continue to support these reports for third party integrations.
+    - The [Gemnasium analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/) project is deprecated, as well as the corresponding container images (all tags and variants): `gemnasium`, `gemnasium-maven`, `gemnasium-python`.
+    These images will not be removed from the GitLab container registry but they are [no longer supported](https://docs.gitlab.com/ee/update/terminology.html#end-of-support) with GitLab 18.0 and later.
+    - The following CI/CD variables associated with the Gemnasium analyzer are also deprecated. While these variables will continue to work when using the Gemnasium analyzer, they will not be effective after migrating to the new Dependency Scanning analyzer.
+    If a variable is also used in another context, the deprecation only applies to the Dependency Scanning feature (for example, `GOOS` and `GOARCH` are not specific to the Dependency Scanning feature).
+    `DS_EXCLUDED_ANALYZERS`, `DS_GRADLE_RESOLUTION_POLICY`, `DS_IMAGE_SUFFIX`, `DS_JAVA_VERSION`, `DS_PIP_DEPENDENCY_PATH`, `DS_PIP_VERSION`, `DS_REMEDIATE_TIMEOUT`, `DS_REMEDIATE`, `GEMNASIUM_DB_LOCAL_PATH`, `GEMNASIUM_DB_REF_NAME`, `GEMNASIUM_DB_REMOTE_URL`,
+    `GEMNASIUM_DB_UPDATE_DISABLED`, `GEMNASIUM_LIBRARY_SCAN_ENABLED`, `GOARCH`, `GOFLAGS`, `GOOS`, `GOPRIVATE`, `GRADLE_CLI_OPTS`, `GRADLE_PLUGIN_INIT_PATH`, `MAVEN_CLI_OPTS`, `PIP_EXTRA_INDEX_URL`, `PIP_INDEX_URL`, `PIPENV_PYPI_MIRROR`, `SBT_CLI_OPTS`.
+    - The following [CI/CD components](https://gitlab.com/components/dependency-scanning/#components) are deprecated and reach end of support in GitLab 18.0: Android, Rust, Swift, Cocoapods. These are replaced by
+    [the main Dependency Scanning CI/CD component](https://gitlab.com/components/dependency-scanning/-/tree/main/templates/main?ref_type=heads) that covers all supported languages and package managers.
+    - The [Resolve a vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#resolve-a-vulnerability) feature **for Yarn projects** is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+    While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+    See the corresponding [deprecation announcement](https://docs.gitlab.com/ee/update/deprecations.html#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects) for more details.
+    - The [Dependency Scanning for JavaScript vendored libraries](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#javascript) feature is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+    While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+    See the corresponding [deprecation announcement](https://docs.gitlab.com/ee/update/deprecations.html#dependency-Scanning-for-javascript-vendored-libraries) for more details.
+
+# ==============================
+# OPTIONAL END-OF-SUPPORT FIELDS
+# ==============================
+#
+# If an End of Support period applies:
+# 1) Share this announcement in the `#spt_managers` Support channel in Slack
+# 2) Mention `@gitlab-com/support` in this merge request.
+#
+  # When support for this feature ends, in XX.YY milestone format.
+  end_of_support_milestone: 18.0
+  # Array of tiers the feature is currently available to,
+  # like [Free, Silver, Gold, Core, Premium, Ultimate]
+  tiers: Ultimate
+  # Links to documentation and thumbnail image
+  documentation_url:
+  image_url:
+  # Use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  video_url:
--- a/data/deprecations/17-9-DS-yarn-resolve-vulnerability.yml
+++ b/data/deprecations/17-9-DS-yarn-resolve-vulnerability.yml
@ -0,0 +1,41 @@
+- title: "Resolve a vulnerability for Dependency Scanning on Yarn projects"
+  # The milestones for the deprecation announcement, and the removal.
+  removal_milestone: "18.0"
+  announcement_milestone: "17.9"
+  # Change breaking_change to false if needed.
+  breaking_change: true
+  window: 1  # Can be 1, 2, or 3 - The window when the breaking change will be deployed on GitLab.com
+  reporter: gonzoyumo  # The GitLab username of the person reporting the change
+  stage: application_security_testing
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/501308
+  # Use the impact calculator https://gitlab-com.gitlab.io/gl-infra/breaking-change-impact-calculator/?
+  impact: low # Can be one of: [critical, high, medium, low]
+  scope: project  # Can be one or a combination of: [instance, group, project]
+  resolution_role: Maintainer  # Can be one of: [Admin, Owner, Maintainer, Developer]
+  manual_task: true  # Can be true or false. Use this to denote whether a resolution action must be performed manually (true), or if it can be automated by using the API or other automation (false).
+  body: |  # (required) Don't change this line.
+    The [Resolve a vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#resolve-a-vulnerability) feature for Yarn projects
+    provided by the Gemnasium analyzer for Dependency Scanning is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+
+    While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+    See details in [the migration guide](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/migration_guide_to_sbom_based_scans.html)
+
+    A replacement feature is planned as part of the [Auto Remediation vision](https://gitlab.com/groups/gitlab-org/-/epics/7186) but no timeline has been set for its delivery.
+# ==============================
+# OPTIONAL END-OF-SUPPORT FIELDS
+# ==============================
+#
+# If an End of Support period applies:
+# 1) Share this announcement in the `#spt_managers` Support channel in Slack
+# 2) Mention `@gitlab-com/support` in this merge request.
+#
+  # When support for this feature ends, in XX.YY milestone format.
+  end_of_support_milestone: 18.0
+  # Array of tiers the feature is currently available to,
+  # like [Free, Silver, Gold, Core, Premium, Ultimate]
+  tiers: Ultimate
+  # Links to documentation and thumbnail image
+  documentation_url: https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#resolve-a-vulnerability
+  image_url:
+  # Use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  video_url:
--- a/db/docs/batched_background_migrations/backfill_packages_debian_project_components_project_id.yml
+++ b/db/docs/batched_background_migrations/backfill_packages_debian_project_components_project_id.yml
@ -1,8 +1,9 @@
 ---
 migration_job_name: BackfillPackagesDebianProjectComponentsProjectId
-description: Backfills sharding key `packages_debian_project_components.project_id` from `packages_debian_project_distributions`.
+description: Backfills sharding key `packages_debian_project_components.project_id`
+  from `packages_debian_project_distributions`.
 feature_category: package_registry
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/157626
 milestone: '17.2'
 queued_migration_version: 20240627133840
-finalized_by: # version of the migration that finalized this BBM
+finalized_by: '20250212025238'
--- a/db/post_migrate/20250212025238_finalize_hk_backfill_packages_debian_project_components_project_id.rb
+++ b/db/post_migrate/20250212025238_finalize_hk_backfill_packages_debian_project_components_project_id.rb
@ -0,0 +1,21 @@
+# frozen_string_literal: true
+
+class FinalizeHkBackfillPackagesDebianProjectComponentsProjectId < Gitlab::Database::Migration[2.2]
+  milestone '17.9'
+
+  disable_ddl_transaction!
+
+  restrict_gitlab_migration gitlab_schema: :gitlab_main_cell
+
+  def up
+    ensure_batched_background_migration_is_finished(
+      job_class_name: 'BackfillPackagesDebianProjectComponentsProjectId',
+      table_name: :packages_debian_project_components,
+      column_name: :id,
+      job_arguments: [:project_id, :packages_debian_project_distributions, :project_id, :distribution_id],
+      finalize: true
+    )
+  end
+
+  def down; end
+end
--- a/db/schema_migrations/20250212025238
+++ b/db/schema_migrations/20250212025238
@ -0,0 +1 @@
+2811c9c9cd1e4a6c2bedc1eea17856d48e7de2e64c9db4bc1217681a1ac5a152
--- a/doc/api/admin/token.md
+++ b/doc/api/admin/token.md
@ -111,6 +111,7 @@ Example response:
 > - [Cluster agent tokens added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/178211) in GitLab 17.9.
 > - [Runner authentication tokens added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179066) in GitLab 17.9.
 > - [OAuth application secrets added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/179035) in GitLab 17.9.
+> - [Incoming email tokens added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/180763) in GitLab 17.9.

 FLAG:
 The availability of this feature is controlled by a feature flag.
@ -130,6 +131,7 @@ Revokes or resets a given token based on the token type. This endpoint supports
 | [Feed tokens](../../security/tokens/_index.md#feed-token)                                    | Reset              |
 | [Runner authentication tokens](../../security/tokens/_index.md#runner-authentication-tokens) | Reset              |
 | [OAuth application secrets](../../integration/oauth_provider.md)                             | Reset              |
+| [Incoming email tokens](../../security/tokens/_index.md#incoming-email-token)                | Reset              |

 ```plaintext
 DELETE /api/v4/admin/token
--- a/doc/development/ai_features/actions.md
+++ b/doc/development/ai_features/actions.md
@ -16,7 +16,7 @@ a given prompt.
 ### 1. Add your action to the Cloud Connector feature list

 The Cloud Connector configuration stores the permissions needed to access your service, as well as additional metadata.
-If there's no entry for your feature, [add the feature as a Cloud Connector unit primitive](../cloud_connector/_index.md#register-new-feature-for-self-managed-dedicated-and-gitlabcom-customers):
+If there's no entry for your feature, [add the feature as a Cloud Connector unit primitive](../cloud_connector/_index.md#register-new-feature-for-gitlab-self-managed-dedicated-and-gitlabcom-customers):

 For more information, see [Cloud Connector: Configuration](../cloud_connector/configuration.md).

--- a/doc/development/cloud_connector/_index.md
+++ b/doc/development/cloud_connector/_index.md
@ -40,7 +40,7 @@ because we do not currently have interfaces in place to self-service this.
 - For GitLab Dedicated and GitLab Self-Managed, the CustomersDot is the **JWT issuer**.
 - For GitLab.com deployment, GitLab.com is the **JWT issuer**, because it's able to [self-sign and create JWTs](architecture.md#gitlabcom) for every request to a Cloud Connector feature.

-#### Register new feature for Self-Managed, Dedicated and GitLab.com customers
+#### Register new feature for GitLab Self-Managed, Dedicated and GitLab.com customers

 You must register the new feature as a unit primitive in the [`gitlab-cloud-connector`](https://gitlab.com/gitlab-org/cloud-connector/gitlab-cloud-connector) repository.
 This repository serves as the Single Source of Truth (SSoT) for all Cloud Connector configurations.
@ -100,9 +100,9 @@ As an example, the feature is delivered as a stand-alone service called `new_fea
     - For a namespace: scopes will be based on purchased add-ons for this namespace
       - If a service can be accessed for free, the token will include all available scopes for that service.
       - For Duo Chat, the **JWT** would include the `documentation_search` and `duo_chat` scopes.
-   - On self-managed, it will always return `::CloudConnector::ServiceAccessToken` **JWT** token.
+   - On GitLab Self-Managed, it will always return `::CloudConnector::ServiceAccessToken` **JWT** token.
     - Provided parameters such as user, namespace or extra claims would be ignored for Self managed instances.
-       Refer to [this section](#the-new-feature-is-introduced-through-the-existing-backend-service) to see how custom claims are handled for self-managed instances.
+       Refer to [this section](#the-new-feature-is-introduced-through-the-existing-backend-service) to see how custom claims are handled for GitLab Self-Managed instances.

   The **backend service** (AI gateway) must validate this token and any scopes it carries when receiving the request.

@ -130,7 +130,7 @@ To decide if the service is available or visible to the end user, we need to:
  ```

 - On GitLab Self-Managed, check if the customer is using an [online cloud license](https://about.gitlab.com/pricing/licensing-faq/cloud-licensing/#what-is-cloud-licensing)
-  - Cloud connector currently only support online cloud license for self-managed customers.
+  - Cloud connector currently only support online cloud license for GitLab Self-Managed customers.
  - Trials or legacy licenses are not supported.
  - GitLab.com is using a legacy license.

@ -245,7 +245,7 @@ See [access token](#access-token-1)

 #### Implement authorization checks in backend service

-GitLab Rails calls a backend service to deliver functionality that would otherwise be unavailable to Self-managed and
+GitLab Rails calls a backend service to deliver functionality that would otherwise be unavailable to GitLab Self-Managed and
 Dedicated instances. For GitLab Rails to be able to call this, there has to be an endpoint exposed.
 The backend service must verify each JWT sent by GitLab Rails in the Authorization header.

--- a/doc/development/cloud_connector/architecture.md
+++ b/doc/development/cloud_connector/architecture.md
@ -20,8 +20,8 @@ terms:

 - **GitLab Rails:** The main GitLab application.
 - **GitLab.com:** The multi-tenant GitLab SaaS deployment operated by GitLab Inc.
- **Dedicated:** A single-tenant GitLab SaaS deployment operated by GitLab Inc.
- **Self-managed:** Any GitLab instance operated by a customer, potentially deployed to a private cloud.
+- **GitLab Dedicated:** A single-tenant GitLab SaaS deployment operated by GitLab Inc.
+- **GitLab Self-Managed:** Any GitLab instance operated by a customer, potentially deployed to a private cloud.
 - **GitLab instance:** Any of the above.
 - **Backend service:** A GitLab-operated web service invoked by a GitLab instance to deliver functionality
  that's part of the Cloud Connector set of features. The AI gateway is one example.
@ -50,7 +50,7 @@ terms:

 Most GitLab features can be delivered directly from a GitLab instance, regardless of where it is deployed.
 Some features, however, require 3rd party vendor integration or are difficult to operate outside of the
-GitLab.com. This presents self-managed and Dedicated customers with a problem since they are not easily
+GitLab.com. This presents GitLab Self-Managed and GitLab Dedicated customers with a problem since they are not easily
 able to access those features.

 Cloud Connector solves this problem by:
@ -157,7 +157,7 @@ The JWT issued for instance access carries the following claims (not exhaustive,
 - `nbf`: The time this token can not be used before (UNIX timestamp), this is set to 5 seconds before the time the token was issued.
 - `iat`: The time this token was issued at (UNIX timestamp), this is set to the time the token was issued.
 - `jti`: The JWT ID, set to a randomly created UUID (e.g.: `0099dd6c-b66e-4787-8ae2-c451d86025ae`).
- `gitlab_realm`: A string to differentiate between requests from self-managed and GitLab.com.
+- `gitlab_realm`: A string to differentiate between requests from GitLab Self-Managed and GitLab.com.
  This is `self-managed` when issued by the Customers Portal and `saas` when issued by GitLab.com.
 - `scopes`: A list of access scopes that define which features this token is valid for. We obtain these
  based on decisions such as how paid features are bundled into GitLab tiers and add-ons.
@ -171,7 +171,7 @@ The JWT issues for user access carries the following claims (not exhaustive, sub
 - `nbf`: The time this token can not be used before (UNIX timestamp), this is set to the time the token was issued.
 - `iat`: The time this token was issued at (UNIX timestamp), this is set to the time the token was issued.
 - `jti`: The JWT ID, set to a randomly created UUID (e.g.: `0099dd6c-b66e-4787-8ae2-c451d86025ae`).
- `gitlab_realm`: A string to differentiate between requests from self-managed and GitLab.com. Either `self-managed` or `saas`.
+- `gitlab_realm`: A string to differentiate between requests from GitLab Self-Managed and GitLab.com. Either `self-managed` or `saas`.
 - `scopes`: A list of access scopes that define which features this token is valid for. We obtain these
  based on decisions such as how paid features are bundled into GitLab tiers and add-ons as well as what features
  are allowed to be accessed with a user token.
@ -184,7 +184,7 @@ services are currently required to:
 - Perform signature verification of JWTs and access scope checks for each request.

 The following flow charts should help to understand what happens when a user consumes a Cloud Connector feature,
-such as talking to an AI chat bot, for both GitLab.com and Dedicated/self-managed deployments.
+such as talking to an AI chat bot, for both GitLab.com and GitLab Dedicated/GitLab Self-Managed deployments.

 ### GitLab.com

@ -215,8 +215,8 @@ sequenceDiagram

 ### GitLab Dedicated/Self-Managed

-For Dedicated and self-managed instances the key problem is one of trust delegation:
-we cannot trust any individual self-managed instance and let them issue tokens, but
+For Dedicated and GitLab Self-Managed instances the key problem is one of trust delegation:
+we cannot trust any individual GitLab Self-Managed instance and let them issue tokens, but
 we can delegate trust by letting an instance regularly authorize itself with CustomersDot,
 which is controlled by GitLab Inc. While we do control GitLab Dedicated instances, for simplicity
 we currently consider them "self-managed" from a Cloud Connector standpoint.
@ -257,7 +257,7 @@ sequenceDiagram
 Cloud Connector access data is structured JSON data that is stored in the instance's local database.
 On top of the IJWT, it contains additional information about the services made available
 such as whether the service is considered fully launched or in beta stage. This information is particularly
-useful for self-managed instances whose upgrade cadence we do not control, because it allows us to
+useful for GitLab Self-Managed instances whose upgrade cadence we do not control, because it allows us to
 sync in data that are subject to change and control access to some GitLab features remotely.

 ### AI gateway
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@ -199,7 +199,7 @@ code. We use the following [definition of done](https://www.agilealliance.org/gl
 To reach the definition of done, the merge request must create no regressions and meet all these criteria:

 - Verified as working in production on GitLab.com.
- Verified as working for self-managed instances.
+- Verified as working for GitLab Self-Managed instances.
 - Verified as supporting [Geo](../../administration/geo/_index.md) through the [self-service framework](../geo/framework.md). For more information, see [Geo is a requirement in the definition of done](../geo/framework.md#geo-is-a-requirement-in-the-definition-of-done).

 If a regression occurs, we prefer you revert the change.
@ -238,7 +238,7 @@ requirements.

   NOTE:
   There isn't a way to know anything about our customers' data on their
-   [self-managed instances](../../subscriptions/self_managed/_index.md), so keep
+   [GitLab Self-Managed instances](../../subscriptions/self_managed/_index.md), so keep
   that in mind for any data implications with your merge request.
 1. Consider self-managed functionality and upgrade paths. The change should consider both:

--- a/doc/development/database/adding_database_indexes.md
+++ b/doc/development/database/adding_database_indexes.md
@ -191,16 +191,16 @@ the post-deployment migrations included in the first MR were executed before mer

 #### New or updated queries might be slow on a large GitLab instance

-It's not possible to check query performance directly on self-managed instances.
+It's not possible to check query performance directly on GitLab Self-Managed instances.
 PostgreSQL produces an execution plan based on the data distribution, so
 guessing query performance is a hard task.

-If you are concerned about the performance of a query on self-managed instances
-and decide that self-managed instances must have an index, follow these recommendations:
+If you are concerned about the performance of a query on GitLab Self-Managed instances
+and decide that GitLab Self-Managed instances must have an index, follow these recommendations:

- For self-managed instances following [zero-downtime](../../update/zero_downtime.md)
+- For GitLab Self-Managed instances following [zero-downtime](../../update/zero_downtime.md)
  upgrades, post-deploy migrations execute when performing an upgrade after the application code deploys.
- For self-managed instances that do not follow a zero-downtime upgrade,
+- For GitLab Self-Managed instances that do not follow a zero-downtime upgrade,
  the administrator might choose to execute the post-deployment migrations for a release later,
  at the time of their choosing, after the regular migrations execute. The application code deploys when they upgrade.

@ -223,7 +223,7 @@ You have two options depending on [how long it takes to create the index](../mig

 PostgreSQL's unique index acts as a constraint. Adding one to an existing table can be tricky.

-Unless the table is absolutely guaranteed to be tiny for GitLab.com and self-managed instances,
+Unless the table is absolutely guaranteed to be tiny for GitLab.com and GitLab Self-Managed instances,
 you must use multiple post-deployment migrations over multiple releases to:

 - Remove and(or) fix the duplicate records.
--- a/doc/development/database/batched_background_migrations.md
+++ b/doc/development/database/batched_background_migrations.md
@ -271,7 +271,7 @@ turn can be handled by defining foreign keys with cascading deletes.

 Finalizing a batched background migration is done by calling
 `ensure_batched_background_migration_is_finished`, after at-least, one required stop from queuing it.
-This ensures a smooth upgrade process for self-managed instances.
+This ensures a smooth upgrade process for GitLab Self-Managed instances.

 It is important to finalize all batched background migrations when it is safe
 to do so. Leaving around old batched background migration is a form of
--- a/doc/development/database/deleting_migrations.md
+++ b/doc/development/database/deleting_migrations.md
@ -6,7 +6,7 @@ title: Delete existing migrations
 ---

 When removing existing migrations from the GitLab project, you have to take into account
-the possibility of the migration already been included in past releases or in the current release, and thus already executed on GitLab.com and/or in self-managed instances.
+the possibility of the migration already been included in past releases or in the current release, and thus already executed on GitLab.com and/or in GitLab Self-Managed instances.

 Because of it, it's not possible to delete existing migrations, as that could lead to:

--- a/doc/development/database/iterating_tables_in_batches.md
+++ b/doc/development/database/iterating_tables_in_batches.md
@ -264,7 +264,7 @@ In this particular example, the database had to read 10 rows (regardless of our
 to determine the first `id` value. In a "real-world" application it's hard to predict whether the
 filtering causes problems or not. In the case of GitLab, verifying the data on a
 production replica is a good start, but keep in mind that data distribution on GitLab.com can be
-different from self-managed instances.
+different from GitLab Self-Managed instances.

 #### Improve filtering with `each_batch`

--- a/doc/development/documentation/styleguide/_index.md
+++ b/doc/development/documentation/styleguide/_index.md
@ -758,10 +758,10 @@ page), use these phrases:

 | Option | Markdown                 | Displayed result       |
 |--------|--------------------------|------------------------|
-| No     | `**{dotted-circle}** No` | **{dotted-circle}** No |
-| Yes    | `**{check-circle}** Yes` | **{check-circle}** Yes |
+| No     | `**{dash-circle}** No` | **{dash-circle}** No |
+| Yes    | `**{check-circle-filled}** Yes` | **{check-circle-filled}** Yes |

-Don't use `**{dotted-circle}**` and `**{check-circle}**` in API documentation.
+Do not use these SVG icons in API documentation.
 Instead, follow the [API topic template](../restful_api_styleguide.md#api-topic-template).

 ### Footnotes
--- a/doc/development/feature_flags/_index.md
+++ b/doc/development/feature_flags/_index.md
@ -74,7 +74,7 @@ When the feature implementation is delivered over multiple merge requests:
   with the implementation. Do not enable the feature flag for a public project
   like `gitlab-org/gitlab` if there is no documentation. Team members and contributors might search for
   documentation on how to use the feature if they see it enabled in a public project.
-1. When the feature is ready for production use, including self-managed instances, open one merge request to:
+1. When the feature is ready for production use, including GitLab Self-Managed instances, open one merge request to:
   - Update the documentation to describe the latest flag status.
   - Add a [changelog entry](#changelog).
   - Remove the feature flag to enable the new behavior, or flip the feature flag to be **enabled by default** (only for `ops` and `beta` feature flags).
--- a/doc/development/gitlab_flavored_markdown/banzai_pipeline_and_parsing.md
+++ b/doc/development/gitlab_flavored_markdown/banzai_pipeline_and_parsing.md
@ -86,7 +86,7 @@ Please see [glfm_markdown.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/l

 Usually the easiest way to debug the various pipelines and filters is to run them from the Rails console. This way you can set a `binding.pry` in a filter and step through the code.

-Because of `TimeoutFilterHandler` and `PipelineTimingCheck`, it can be a challenge to debug the filters. There is a special environment variable, `GITLAB_DISABLE_MARKDOWN_TIMEOUT`, that when set disables any timeout checking in the filters. This is also available for customers in the rare instance that a [self-managed instance](../../administration/environment_variables.md) wishes to bypass those checks.
+Because of `TimeoutFilterHandler` and `PipelineTimingCheck`, it can be a challenge to debug the filters. There is a special environment variable, `GITLAB_DISABLE_MARKDOWN_TIMEOUT`, that when set disables any timeout checking in the filters. This is also available for customers in the rare instance that a [GitLab Self-Managed instance](../../administration/environment_variables.md) wishes to bypass those checks.

 ```ruby
 text = 'Some test **Markdown**'
--- a/doc/development/internal_analytics/_index.md
+++ b/doc/development/internal_analytics/_index.md
@ -209,7 +209,7 @@ flowchart LR;

 ## Data Privacy

-GitLab only receives event counts or similarly aggregated information from self-managed instances. User identifiers for individual events on the SaaS version of GitLab are [pseudonymized](https://metrics.gitlab.com/identifiers/).
+GitLab only receives event counts or similarly aggregated information from GitLab Self-Managed instances. User identifiers for individual events on the SaaS version of GitLab are [pseudonymized](https://metrics.gitlab.com/identifiers/).
 An exact description on what kind of data is being collected through the Internal Analytics system is given in our [handbook](https://handbook.gitlab.com/handbook/legal/privacy/customer-product-usage-information/).

 ## Contribution guidelines
--- a/doc/development/internal_analytics/internal_event_instrumentation/local_setup_and_debugging.md
+++ b/doc/development/internal_analytics/internal_event_instrumentation/local_setup_and_debugging.md
@ -83,7 +83,7 @@ The Monitor's Keyboard commands:

 ## Snowplow Micro

-By default, self-managed instances do not collect event data through Snowplow. We can use [Snowplow Micro](https://docs.snowplow.io/docs/testing-debugging/snowplow-micro/what-is-micro/), a Docker based Snowplow collector, to test events locally:
+By default, GitLab Self-Managed instances do not collect event data through Snowplow. We can use [Snowplow Micro](https://docs.snowplow.io/docs/testing-debugging/snowplow-micro/what-is-micro/), a Docker based Snowplow collector, to test events locally:

 1. Ensure [Docker is installed and working](https://www.docker.com/get-started/).

@ -152,7 +152,7 @@ It works in production, staging, and local development environments. It is espec

 ## Remote event collector

-On GitLab.com events are sent to a collector configured by GitLab. By default, self-managed instances do not have a collector configured and do not collect data with Snowplow.
+On GitLab.com events are sent to a collector configured by GitLab. By default, GitLab Self-Managed instances do not have a collector configured and do not collect data with Snowplow.

 You can configure your instance to use a custom Snowplow collector.

--- a/doc/development/internal_analytics/internal_event_instrumentation/migration.md
+++ b/doc/development/internal_analytics/internal_event_instrumentation/migration.md
@ -15,7 +15,7 @@ While we encourage you to migrate to Internal Event tracking the deprecated meth

 ## Migrating from existing Snowplow tracking

-If you are already tracking events in Snowplow, you can also start collecting metrics from self-managed instances by switching to Internal Events Tracking.
+If you are already tracking events in Snowplow, you can also start collecting metrics from GitLab Self-Managed instances by switching to Internal Events Tracking.

 The event triggered by Internal Events has some special properties compared to previously tracking with Snowplow directly:

--- a/doc/development/internal_analytics/metrics/metrics_dictionary.md
+++ b/doc/development/internal_analytics/metrics/metrics_dictionary.md
@ -48,9 +48,9 @@ Each metric is defined in a YAML file consisting of a number of fields:
 | `performance_indicator_type` | no       | `array`; may be set to one of [`gmau`, `smau`, `paid_gmau`, `umau`, `customer_health_score`, `devops_report`, `lighthouse`, or `leading_indicator`](https://handbook.gitlab.com/handbook/business-technology/data-team/data-catalog/). |
 | `tier`                       | yes      | `array`; may contain one or a combination of `free`, `premium` or `ultimate`. The [tier](https://handbook.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available. This should be verbose and contain all tiers where a metric is available. |
 | `tiers`                       | no      | `array`; may contain one or a combination of `free`, `premium` or `ultimate`. The [tiers](https://handbook.gitlab.com/handbook/marketing/brand-and-product-marketing/product-and-solution-marketing/tiers/#definitions) where the tracked feature is available. This should be verbose and contain all tiers where a metric is available. |
-| `milestone`                  | yes      | The milestone when the metric is introduced and when it's available to self-managed instances with the official GitLab release. |
+| `milestone`                  | yes      | The milestone when the metric is introduced and when it's available to GitLab Self-Managed instances with the official GitLab release. |
 | `milestone_removed`          | no       | The milestone when the metric is removed. Required for removed metrics. |
-| `introduced_by_url`          | yes      | The URL to the merge request that introduced the metric to be available for self-managed instances. |
+| `introduced_by_url`          | yes      | The URL to the merge request that introduced the metric to be available for GitLab Self-Managed instances. |
 | `removed_by_url`             | no       | The URL to the merge request that removed the metric. Required for removed metrics. |
 | `repair_issue_url`           | no       | The URL of the issue that was created to repair a metric with a `broken` status. |
 | `options`                    | no       | `object`: options information needed to calculate the metric value. |
--- a/doc/development/internal_analytics/metrics/metrics_lifecycle.md
+++ b/doc/development/internal_analytics/metrics/metrics_lifecycle.md
@ -53,7 +53,7 @@ Currently, the [Metrics Dictionary](https://metrics.gitlab.com/) is built automa
   - Set `milestone_removed:` to the number of the
     milestone in which the metric was removed.

-   Do not remove the metric's YAML definition altogether. Some self-managed instances might not immediately update to the latest version of GitLab, and
+   Do not remove the metric's YAML definition altogether. Some GitLab Self-Managed instances might not immediately update to the latest version of GitLab, and
   therefore continue to report the removed metric. The Analytics Instrumentation team requires a record of all removed metrics to identify and filter them.

 ## Group name changes
--- a/doc/development/internal_analytics/service_ping/_index.md
+++ b/doc/development/internal_analytics/service_ping/_index.md
@ -18,7 +18,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](../../../administration/settings/usage_statistics.md#enable-or-disable-service-ping) certain metrics 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-service-ping) certain metrics on any GitLab 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/observability/_index.md
+++ b/doc/development/observability/_index.md
@ -17,7 +17,7 @@ There are several options for developing and debugging GitLab Observability:

 ### Run GDK and connect to the staging instance of GitLab Observability Backend

-This method takes advantage of our Cloud Connected Observability Backend. Your GitLab instance will require a valid Cloud License and will be treated as a self-managed instance, connected to a multi-tenant GitLab-hosted instance of the GitLab Observability Backend. See [this design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/observability_for_self_managed/) for more details on how this works.
+This method takes advantage of our Cloud Connected Observability Backend. Your GitLab instance will require a valid Cloud License and will be treated as a GitLab Self-Managed instance, connected to a multi-tenant GitLab-hosted instance of the GitLab Observability Backend. See [this design document](https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/observability_for_self_managed/) for more details on how this works.

 How to enable:

--- a/doc/development/redis/new_redis_instance.md
+++ b/doc/development/redis/new_redis_instance.md
@ -232,7 +232,7 @@ Variable assignments within `pipelined` and `multi` blocks are not advised as th

 <!-- markdownlint-disable MD044 -->
 We may choose to keep the migration paths or remove them, depending on whether
-or not we expect self-managed instances to perform this migration.
+or not we expect GitLab Self-Managed instances to perform this migration.
 [gitlab-com/gl-infra/scalability#1131](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/1131#note_603354746)
 contains a discussion on this topic for the trace chunks feature flag. It may
 be - as in that case - that we decide that the maintenance costs of supporting
--- a/doc/development/rubocop_development_guide.md
+++ b/doc/development/rubocop_development_guide.md
@ -178,7 +178,7 @@ and run `bundle exec gitlab-housekeeper -k Keeps::GenerateRubocopTodos`.

 ## Reveal existing RuboCop exceptions

-To reveal existing RuboCop exceptions in the code that have been excluded via `.rubocop_todo.yml` and
+To reveal existing RuboCop exceptions in the code that have been excluded via
 `.rubocop_todo/**/*.yml`, set the environment variable `REVEAL_RUBOCOP_TODO` to `1`.

 This allows you to reveal existing RuboCop exceptions during your daily work cycle and fix them along the way.
--- a/doc/development/sidekiq/_index.md
+++ b/doc/development/sidekiq/_index.md
@ -187,7 +187,7 @@ If you want to allow instance administrators to control the concurrency limit:
 concurrency_limit -> { ApplicationSetting.current.some_feature_concurrent_sidekiq_jobs }
 ```

-This approach also allows having separate limits for .com and self-managed instances. To achieve this, you can:
+This approach also allows having separate limits for .com and GitLab Self-Managed instances. To achieve this, you can:

 1. Create a migration to add the configuration option with a default set to the self-managed limit.
 1. In the same MR, ship a migration to update the limit for .com only.
--- a/doc/editor_extensions/eclipse/setup.md
+++ b/doc/editor_extensions/eclipse/setup.md
@ -18,23 +18,6 @@ Please do not rely on this information for purchasing or planning purposes.
 The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
 sole discretion of GitLab Inc.

-## Add the GitLab Releases software site
-
-To add the stable GitLab Releases software site:
-
-1. In your IDE, select **Eclipse > Settings...**.
-1. On the left sidebar, expand **Install/Update**, then select **Available Software Sites**.
-1. On the right, select **Add...** to configure a new software site.
-1. For **Name:**, use `GitLab Releases`.
-1. For **Location:**, copy and paste the following URL:
-
-   ```plaintext
-   https://gitlab.com/gitlab-org/editor-extensions/gitlab-eclipse-plugin/-/releases/permalink/latest/downloads/
-   ```
-
-1. Select **Add**.
-1. Select **Apply and Close**.
-
 ## Install the GitLab for Eclipse plugin

 Prerequisites:
@ -44,12 +27,13 @@ Prerequisites:

 To install GitLab for Eclipse:

-1. In your IDE, select the **Help** menu.
-1. Select **Install New Software...**.
-1. Expand **Work with:**, then select the `GitLab Releases` software site.
-1. Select **Show only software applicable to target environment**.
-1. Select the **GitLab** category to install the GitLab for Eclipse plugin and dependencies.
-1. Select **Next >**, then select **Finish**.
+1. Open your Eclipse IDE and your preferred web browser.
+1. In your web browser, go to the page for the
+   [GitLab for Eclipse plugin](https://marketplace.eclipse.org/content/gitlab-eclipse) in the Eclipse Marketplace.
+1. On the plugin's page, select **Install**, and drag your mouse over to your Eclipse IDE.
+1. In the **Eclipse Marketplace** window, select the **GitLab For Eclipse** category.
+1. Select **Confirm >**, then select **Finish**.
+1. If the **Trust Authorities** window appears, select the **[`https://gitlab.com`](https://gitlab.com)** update site and select **Trust Selected**.
 1. Select **Restart Now**.

 ## Connect to GitLab
--- a/doc/legal/licensing_policy.md
+++ b/doc/legal/licensing_policy.md
@ -90,7 +90,7 @@ Customers may have multiple instances of GitLab.com or Dedicated, provided that
 This is technically possible, subject to certain conditions:

 Subject to the terms of a written agreement between customer and GitLab, one Cloud Licensing activation code (or license key) may
-be applied to multiple self-managed instances provided that the users on the instances:
+be applied to multiple GitLab Self-Managed instances provided that the users on the instances:

 - Are the same, or
 - Are a subset of the customer's licensed production instance.
@ -101,7 +101,7 @@ as long as the user list is the same, the activation code (or license key) will

 However, if either of the conditions above are not met, customer will need to purchase an additional subscription for a separate instance for those users.

-## Use of multiple self-managed instances with a single license key or activation code
+## Use of multiple GitLab Self-Managed instances with a single license key or activation code

 ### Validating when one license or activation code is applied to multiple instances

@ -135,9 +135,9 @@ This will provide the customer with the relevant license file, but also with an

 Customers are welcome to apply their production license key or activation code to a development environment. The same user restrictions will apply.

-### Using a single subscription for a GitLab.com, Dedicated, and self-managed instance
+### Using a single subscription for a GitLab.com, Dedicated, and GitLab Self-Managed instance

-If the customer wants to have GitLab.com, Dedicated, and self-managed instances, the customer will need to purchase separate subscriptions for each instance.
+If the customer wants to have GitLab.com, Dedicated, and GitLab Self-Managed instances, the customer will need to purchase separate subscriptions for each instance.

 ### Example Scenarios

@ -146,7 +146,7 @@ The following scenarios reflect questions a customer may ask related to multiple
 #### Example 1

 - Q: I want to buy a license for 50 total users, but want to split these users into two instances. Can I do this?
- A: Yes, provided it is for two self-managed instances, you can apply one Cloud Licensing activation code (or license key) to multiple self-managed instances,
+- A: Yes, provided it is for two GitLab Self-Managed instances, you can apply one Cloud Licensing activation code (or license key) to multiple GitLab Self-Managed instances,
  provided that the users on the instances are the same, or are a subset of the total users. In this case, since there are 50 total or unique users, you may split
  those users into two subset instances.

--- a/doc/security/hardening_nist_800_53.md
+++ b/doc/security/hardening_nist_800_53.md
@ -10,7 +10,7 @@ DETAILS:
 **Offering:** GitLab Self-Managed, GitLab Dedicated

 This page provides a reference for GitLab administrators
-who want to configure self-managed instances to meet applicable
+who want to configure GitLab Self-Managed instances to meet applicable
 NIST 800-53 controls. GitLab does not provide specific configuration
 guidance because of the variety of requirements an administrator might have.
 Before you deploy a GitLab instance that meets the NIST 800-53 security controls,
@ -171,7 +171,7 @@ requirements:

 - [Credentials inventory](../administration/credentials_inventory.md)
  enables administrators to review all secrets used in a GitLab
-  self-managed instance in one place. A consolidated view of
+  GitLab Self-Managed instance in one place. A consolidated view of
  credentials, tokens, and keys may assist with satisfying
  requirements such as reviewing passwords or rotating credentials.

@ -456,7 +456,7 @@ organizational needs prior to establishing a contingency plan.
 **Selecting a GitLab Architecture**

 GitLab provides extensive documentation on the architectures supported
-in a self-managed instance. GitLab supports the following cloud service
+in a GitLab Self-Managed instance. GitLab supports the following cloud service
 providers:

 - [Azure](../install/azure/_index.md)
--- a/doc/update/breaking_windows.md
+++ b/doc/update/breaking_windows.md
@ -45,6 +45,9 @@ This window takes place on April 21 - 23, 2025 from 09:00 UTC to 22:00 UTC.
 | [Workspaces `editor` GraphQL field is deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/508155) | Low | Create | Project |
 | [Enforce keyset pagination on audit event API](https://gitlab.com/gitlab-org/gitlab/-/issues/382338) | Low | Software supply chain security | Instance, group, project |
 | [Fix typo in user profile visibility updated audit event type](https://gitlab.com/gitlab-org/gitlab/-/issues/474386) | Low | Software supply chain security | Instance |
+| [Dependency Scanning for JavaScript vendored libraries](https://gitlab.com/gitlab-org/gitlab/-/issues/501308) | Low | Application_security_testing | Project |
+| [Dependency Scanning upgrades to the GitLab SBOM Vulnerability Scanner](https://gitlab.com/gitlab-org/gitlab/-/issues/501308) | High | Application_security_testing | Project |
+| [Resolve a vulnerability for Dependency Scanning on Yarn projects](https://gitlab.com/gitlab-org/gitlab/-/issues/501308) | Low | Application_security_testing | Project |
 | [API Discovery will use branch pipelines by default](https://gitlab.com/gitlab-org/gitlab/-/issues/515487) | Low | Application_security_testing | Project |
 | [Container Scanning default severity threshold set to `medium`](https://gitlab.com/gitlab-org/gitlab/-/issues/515358) | Low | Application security testing | Project |
 | [Subscription related API endpoints in the public API are deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/515371#note_2319368251) | Low | Fulfillment | Instance |
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@ -592,6 +592,82 @@ This is a breaking change. Before you upgrade, create new access tokens with the

 <div class="deprecation breaking-change" data-milestone="18.0">

+### Dependency Scanning for JavaScript vendored libraries
+
+<div class="deprecation-notes">
+
+- Announced in GitLab <span class="milestone">17.9</span>
+- End of Support in GitLab <span class="milestone">18.0</span>
+- Removal in GitLab <span class="milestone">18.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/501308).
+
+</div>
+
+The [Dependency Scanning for JavaScript vendored libraries](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#javascript) feature
+provided by the Gemnasium analyzer for Dependency Scanning is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+
+While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+See details in [the migration guide](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/migration_guide_to_sbom_based_scans.html)
+
+A replacement feature will be developed with [Dependency Scanning on vendored libraries](https://gitlab.com/groups/gitlab-org/-/epics/7186) but no timeline has been set for its delivery.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="18.0">
+
+### Dependency Scanning upgrades to the GitLab SBOM Vulnerability Scanner
+
+<div class="deprecation-notes">
+
+- Announced in GitLab <span class="milestone">17.9</span>
+- End of Support in GitLab <span class="milestone">18.0</span>
+- Removal in GitLab <span class="milestone">18.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/501308).
+
+</div>
+
+The Dependency Scanning feature is upgrading to the GitLab SBOM Vulnerability Scanner. As part of this change, the Gemnasium analyzer (previously used in CI/CD pipelines) is deprecated in GitLab 17.9
+and reaches [end of support](https://docs.gitlab.com/ee/update/terminology.html#end-of-support) in GitLab 18.0.
+It is replaced with the [new Dependency Scanning analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/dependency-scanning) that focuses on detecting dependencies and their relationships (dependency graph).
+This upgrade represents a fundamental shift: instead of performing security analysis within CI pipelines, the new system uses GitLab's built-in SBOM Vulnerability Scanner, which is already employed by
+[Continuous Vulnerability Scanning](https://docs.gitlab.com/ee/user/application_security/continuous_vulnerability_scanning/).
+
+Due to the significant changes and feature removals this upgrade introduces, it will not be implemented automatically. While some breaking changes will take effect in GitLab 18.0, existing CI/CD jobs
+using the Gemnasium analyzer will continue to function by default to prevent disruption to CI configurations.
+
+Please review the fully detailed changes below and consult [the migration guide](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/migration_guide_to_sbom_based_scans.html) to assist you with the transition.
+
+- When using the Dependency Scanning CI/CD template (`Dependency-Scanning.gitlab-ci.yml`), the existing CI/CD jobs based on the Gemnasium analyzer will continue to be used by default. The new Dependency Scanning analyzer will run by default only
+for newly supported languages and package managers that are not already covered by the Gemnasium analyzer. You can also opt-in to fully migrate to the new Dependency Scanning analyzer and use for all supported projects.
+- To transition to Dependency Scanning with SBOM, the security scan results generated by the Gemansium analyzer will no longer be uploaded to the GitLab platform as a
+[Dependency Scanning security report artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdependency_scanning). Instead, Dependency Scanning results will be generated within the GitLab platform,
+using the GitLab SBOM Vulnerability Scanner, and based on the [CycloneDX SBOM report artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportscyclonedx) generated in the CI/CD pipeline.
+As a result, any workflows that rely on modifying security scan results before uploading them to the GitLab platform will be impacted.
+However, the Dependency Scanning JSON report will continue to be produced by the Gemnasium analyzer and exported as [a standard job artifact](https://docs.gitlab.com/ee/ci/yaml/index.html#artifactspaths) so that any workflow that consumes this
+report in a succeeding CI/CD job will continue to work. Please note that further improvements made to the GitLab SBOM Vulnerability Scanner will not be reflected in this JSON report.
+Since the new Dependency Scanning analyzer does not generate any security report, when migrating users must use the ([`Pipeline.securityReportFindings` resource](https://docs.gitlab.com/ee/api/graphql/reference/index.html#pipelinesecurityreportfindings))
+of the GraphQL API to programmatically consume security scan results.
+The ability to [download security scan results via the UI](https://docs.gitlab.com/ee/user/application_security/detect/security_scan_results.html#all-tiers) in this format for the GitLab Dependency Scanning feature is also removed in GitLab 18.0.
+The [Dependency Scanning security report artifact](https://docs.gitlab.com/ee/ci/yaml/artifacts_reports.html#artifactsreportsdependency_scanning) itself is not deprecated and GitLab will continue to support these reports for third party integrations.
+- The [Gemnasium analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/) project is deprecated, as well as the corresponding container images (all tags and variants): `gemnasium`, `gemnasium-maven`, `gemnasium-python`.
+These images will not be removed from the GitLab container registry but they are [no longer supported](https://docs.gitlab.com/ee/update/terminology.html#end-of-support) with GitLab 18.0 and later.
+- The following CI/CD variables associated with the Gemnasium analyzer are also deprecated. While these variables will continue to work when using the Gemnasium analyzer, they will not be effective after migrating to the new Dependency Scanning analyzer.
+If a variable is also used in another context, the deprecation only applies to the Dependency Scanning feature (for example, `GOOS` and `GOARCH` are not specific to the Dependency Scanning feature).
+`DS_EXCLUDED_ANALYZERS`, `DS_GRADLE_RESOLUTION_POLICY`, `DS_IMAGE_SUFFIX`, `DS_JAVA_VERSION`, `DS_PIP_DEPENDENCY_PATH`, `DS_PIP_VERSION`, `DS_REMEDIATE_TIMEOUT`, `DS_REMEDIATE`, `GEMNASIUM_DB_LOCAL_PATH`, `GEMNASIUM_DB_REF_NAME`, `GEMNASIUM_DB_REMOTE_URL`,
+`GEMNASIUM_DB_UPDATE_DISABLED`, `GEMNASIUM_LIBRARY_SCAN_ENABLED`, `GOARCH`, `GOFLAGS`, `GOOS`, `GOPRIVATE`, `GRADLE_CLI_OPTS`, `GRADLE_PLUGIN_INIT_PATH`, `MAVEN_CLI_OPTS`, `PIP_EXTRA_INDEX_URL`, `PIP_INDEX_URL`, `PIPENV_PYPI_MIRROR`, `SBT_CLI_OPTS`.
+- The following [CI/CD components](https://gitlab.com/components/dependency-scanning/#components) are deprecated and reach end of support in GitLab 18.0: Android, Rust, Swift, Cocoapods. These are replaced by
+[the main Dependency Scanning CI/CD component](https://gitlab.com/components/dependency-scanning/-/tree/main/templates/main?ref_type=heads) that covers all supported languages and package managers.
+- The [Resolve a vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#resolve-a-vulnerability) feature **for Yarn projects** is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+See the corresponding [deprecation announcement](https://docs.gitlab.com/ee/update/deprecations.html#resolve-a-vulnerability-for-dependency-scanning-on-yarn-projects) for more details.
+- The [Dependency Scanning for JavaScript vendored libraries](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#javascript) feature is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+See the corresponding [deprecation announcement](https://docs.gitlab.com/ee/update/deprecations.html#dependency-Scanning-for-javascript-vendored-libraries) for more details.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="18.0">
+
 ### Deprecate CI job implementation of Repository X-Ray

 <div class="deprecation-notes">
@ -1496,6 +1572,29 @@ The namespace GraphQL field `add_on_purchase` will be deprecated in GitLab 17.5

 <div class="deprecation breaking-change" data-milestone="18.0">

+### Resolve a vulnerability for Dependency Scanning on Yarn projects
+
+<div class="deprecation-notes">
+
+- Announced in GitLab <span class="milestone">17.9</span>
+- End of Support in GitLab <span class="milestone">18.0</span>
+- Removal in GitLab <span class="milestone">18.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/501308).
+
+</div>
+
+The [Resolve a vulnerability](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/#resolve-a-vulnerability) feature for Yarn projects
+provided by the Gemnasium analyzer for Dependency Scanning is deprecated in GitLab 17.9 and reaches end of support in GitLab 18.0.
+
+While this functionality will continue to work when using the Gemnasium analyzer, it will not be available after migrating to the new Dependency Scanning analyzer.
+See details in [the migration guide](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/migration_guide_to_sbom_based_scans.html)
+
+A replacement feature is planned as part of the [Auto Remediation vision](https://gitlab.com/groups/gitlab-org/-/epics/7186) but no timeline has been set for its delivery.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="18.0">
+
 ### Runner `active` GraphQL fields replaced by `paused`

 <div class="deprecation-notes">
--- a/doc/user/application_security/dependency_list/_index.md
+++ b/doc/user/application_security/dependency_list/_index.md
@ -119,23 +119,19 @@ The dependency path is only displayed for dependencies that have vulnerabilities
 Dependency paths are supported for the following package managers:

 - [Conan](https://conan.io)
- [Gradle](https://gradle.org/)&nbsp;<sup><strong><a href="#notes-regarding-dependency-path-support">1</a></strong></sup>
- [Maven](https://maven.apache.org/)&nbsp;<sup><strong><a href="#notes-regarding-dependency-path-support">1</a></strong></sup>
- [NPM](https://www.npmjs.com/)&nbsp;<sup><strong><a href="#notes-regarding-dependency-path-support">1</a></strong></sup>
 - [NuGet](https://www.nuget.org/)
- [Pipenv](https://pipenv.pypa.io/en/latest/)&nbsp;<sup><strong><a href="#notes-regarding-dependency-path-support">1</a></strong></sup>
- [pip-tools](https://pip-tools.readthedocs.io/en/latest/)&nbsp;<sup><strong><a href="#notes-regarding-dependency-path-support">1</a></strong></sup>
- [pnpm](https://pnpm.io/)&nbsp;<sup><strong><a href="#notes-regarding-dependency-path-support">1</a></strong></sup>
- [Poetry](https://python-poetry.org/)&nbsp;<sup><strong><a href="#notes-regarding-dependency-path-support">1</a></strong></sup>
 - [sbt](https://www.scala-sbt.org)
 - [Yarn 1.x](https://classic.yarnpkg.com/lang/en/)

-<ol>
-  <li>
-    <a id="notes-regarding-dependency-path-support"></a>
-    <p>Supported only when using the <a href="https://gitlab.com/components/dependency-scanning/-/tree/main/templates/main">`dependency-scanning` component</a>.</p>
-  </li>
-</ol>
+Dependency paths are supported for the following package managers only when using the [`dependency-scanning`](https://gitlab.com/components/dependency-scanning/-/tree/main/templates/main) component:
+
+- [Gradle](https://gradle.org/)
+- [Maven](https://maven.apache.org/)
+- [NPM](https://www.npmjs.com/)
+- [Pipenv](https://pipenv.pypa.io/en/latest/)
+- [pip-tools](https://pip-tools.readthedocs.io/en/latest/)
+- [pnpm](https://pnpm.io/)
+- [Poetry](https://python-poetry.org/)

 ### Licenses

--- a/doc/user/application_security/dependency_scanning/_index.md
+++ b/doc/user/application_security/dependency_scanning/_index.md
@ -46,6 +46,12 @@ DETAILS:
 **Tier:** Ultimate
 **Offering:** GitLab.com, GitLab Self-Managed, GitLab Dedicated

+WARNING:
+The Dependency Scanning feature based on the Gemnasium analyzer is deprecated in GitLab 17.9 and reaches
+end of support in GitLab 18.0. It is replaced with [Dependency Scanning using SBOM](dependency_scanning_sbom/_index.md)
+and the [new Dependency Scanning analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/dependency-scanning).
+For more information, see [issue 501038](https://gitlab.com/gitlab-org/gitlab/-/issues/501308).
+
 Dependency Scanning analyzes your application's dependencies for known vulnerabilities. All
 dependencies are scanned, including transitive dependencies, also known as nested dependencies.

--- a/doc/user/group/compliance_frameworks.md
+++ b/doc/user/group/compliance_frameworks.md
@ -59,8 +59,8 @@ You can apply multiple compliance frameworks to a project but cannot apply compl
 To apply a compliance framework to a project, apply the compliance framework through the
 [Compliance projects report](../compliance/compliance_center/compliance_projects_report.md#apply-a-compliance-framework-to-projects-in-a-group).

-You can use the [GraphQL API](../../api/graphql/reference/_index.md#mutationprojectsetcomplianceframework) to apply a
-compliance framework to a project.
+You can use the [GraphQL API](../../api/graphql/reference/_index.md#mutationprojectupdatecomplianceframeworks) to apply one or many
+compliance frameworks to a project.

 If you create compliance frameworks on subgroups with GraphQL, the framework is created on the root ancestor if the user
 has the correct permissions. The GitLab UI presents a read-only view to discourage this behavior.
--- a/doc/user/group/saml_sso/scim_setup.md
+++ b/doc/user/group/saml_sso/scim_setup.md
@ -144,19 +144,13 @@ The following table provides attribute mappings that are required for GitLab.
 |:---------------------------------------------------------------------------|:-------------------------------|:--------------------|
 | `objectId`                                                                 | `externalId`                   | 1                   |
 | `userPrincipalName` OR `mail` <sup>1</sup>                                 | `emails[type eq "work"].value` |                     |
-| `mailNickname`                                                    | `userName`                     |                     |
+| `mailNickname`                                                             | `userName`                     |                     |
 | `displayName` OR `Join(" ", [givenName], [surname])` <sup>2</sup>          | `name.formatted`               |                     |
 | `Switch([IsSoftDeleted], , "False", "True", "True", "False")` <sup>3</sup> | `active`                       |                     |

-<html>
-<small>
-  <ol>
-    <li>Use <code>mail</code> as a source attribute when the <code>userPrincipalName</code> is not an email address or is not deliverable.</li>
-    <li>Use the <code>Join</code> expression if your <code>displayName</code> does not match the format of <code>Firstname Lastname</code>.</li>
-    <li>This is an expression mapping type, not a direct mapping. Select <b>Expression</b> in the <b>Mapping type</b> dropdown list.</li>
-  </ol>
-</small>
-</html>
+1. Use `mail` as a source attribute when the `userPrincipalName` is not an email address or is not deliverable.
+1. Use the `Join` expression if your `displayName` does not match the format of `Firstname Lastname`.
+1. This is an expression mapping type, not a direct mapping. Select `Expression` in the **Mapping type** dropdown list.

 Each attribute mapping has:

--- a/doc/user/project/merge_requests/approvals/_index.md
+++ b/doc/user/project/merge_requests/approvals/_index.md
@ -71,6 +71,8 @@ Use cases include:

 ## View approval status

+> - More granular approver display [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/178005) in GitLab 17.9 [with a flag](../../../../administration/feature_flags.md) named `mr_approvers_filter_hidden_users`. Enabled by default.
+
 You can see the approval status of a merge request in two places. On the [merge request itself](#for-a-single-merge-request)
 and in the [list of merge requests](#in-the-list-of-merge-requests) for your project or group.

@ -95,6 +97,14 @@ The widget displays one of these statuses:

 To check if your approval satisfies Code Owner requirements, select **Expand eligible approvers** (**{chevron-lg-down}**).

+If you have enabled the `mr_approvers_filter_hidden_users` feature flag, introduced in GitLab 17.9,
+approver visibility depends on your project membership, and group privacy:
+
+- Project members see all approvers.
+- Project non-members see:
+  - All approvers, if the approvers are all from public groups.
+  - No information about approvers, if any of the approvers are from private groups.
+
 ### In the list of merge requests

 The list of merge requests for [your project or group](../_index.md#view-merge-requests)
--- a/doc/user/project/merge_requests/duo_in_merge_requests.md
+++ b/doc/user/project/merge_requests/duo_in_merge_requests.md
@ -10,6 +10,13 @@ DETAILS:
 **Tier:** Ultimate with GitLab Duo Enterprise - [Start a trial](https://about.gitlab.com/solutions/gitlab-duo-pro/sales/?type=free-trial)
 **Offering:** GitLab.com

+DISCLAIMER:
+This page contains information related to upcoming products, features, and functionality.
+It is important to note that the information presented is for informational purposes only.
+Please do not rely on this information for purchasing or planning purposes.
+The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
+sole discretion of GitLab Inc.
+
 GitLab Duo is designed to provide contextually relevant information during the lifecycle of a merge request.

 ## Generate a description by summarizing code changes
@ -43,34 +50,36 @@ DETAILS:
 **Status:** Experiment
 **LLM:** Anthropic [Claude 3.5 Sonnet](https://console.cloud.google.com/vertex-ai/publishers/anthropic/model-garden/claude-3-5-sonnet)

-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/14825) in GitLab 17.5 as an [experiment](../../../policy/development_stages_support.md#experiment).
-> - Feature flag `ai_review_merge_request` [disabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/456106).
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/14825) in GitLab 17.5 as an [experiment](../../../policy/development_stages_support.md#experiment) behind two feature flags named [`ai_review_merge_request`](https://gitlab.com/gitlab-org/gitlab/-/issues/456106) and [`duo_code_review_chat`](https://gitlab.com/gitlab-org/gitlab/-/issues/508632), both disabled by default.
+> - Feature flags [`ai_review_merge_request`](https://gitlab.com/gitlab-org/gitlab/-/issues/456106) and [`duo_code_review_chat`](https://gitlab.com/gitlab-org/gitlab/-/issues/508632) enabled for GitLab.com in 17.10.

 FLAG:
-The availability of this feature is controlled by a feature flag.
+The availability of this feature is controlled by two feature flags.
 For more information, see the history.

 WARNING:
-This feature is considered [experimental](../../../policy/development_stages_support.md) and is not intended for customer usage outside of initial design partners. We expect major changes to this feature.
+This feature is considered [experimental](../../../policy/development_stages_support.md) and breaking changes may still be made to this feature.

-DISCLAIMER:
-This page contains information related to upcoming products, features, and functionality.
-It is important to note that the information presented is for informational purposes only.
-Please do not rely on this information for purchasing or planning purposes.
-The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
-sole discretion of GitLab Inc.
-
-When your merge request is ready to be reviewed, use GitLab Duo Code Review to perform an initial review.
+When your merge request is ready to be reviewed, use GitLab Duo Code Review to perform an initial review:

 1. On the left sidebar, select **Search or go to** and find your project.
 1. Select **Code > Merge requests** and find your merge request.
-1. In a comment box enter the quick action `/assign_reviewer @GitLabDuo` or assign GitLab Duo as reviewer.
+1. In a comment box, enter the quick action `/assign_reviewer @GitLabDuo`, or assign GitLab Duo as reviewer.
+
+NOTE:
+Provide feedback on this feature in issue [517386](https://gitlab.com/gitlab-org/gitlab/-/issues/517386).

 **Data usage**: When you use this feature, the following data is sent to the large language model:

 - Contents of the file
 - The filename

+### Interact with GitLab Duo in reviews
+
+You can mention `@GitLabDuo` in comments to interact with GitLab Duo on your merge request. You can ask follow-up questions on its review comments, or ask questions on any discussion thread in your merge request.
+
+Interactions with GitLab Duo can help to improve the suggestions and feedback as you work to improve your merge request.
+
 ## Summarize a code review

 DETAILS:
--- a/doc/user/project/settings/import_export.md
+++ b/doc/user/project/settings/import_export.md
@ -35,7 +35,7 @@ self-managed instance.

 When migrating projects by using file exports, an administrator's access token is required for user contributions to map correctly.

-Therefore, user contributions never map correctly when importing file exports from a self-managed instance to GitLab.com.
+Therefore, user contributions never map correctly when importing file exports from a GitLab Self-Managed instance to GitLab.com.
 Instead, all GitLab user associations (such as comment author) are changed to the user importing the project. To preserve
 contribution history, do one of the following:

@ -321,8 +321,8 @@ Using file exports, you can:
 - Migrate groups one by one, then export and import each project for the groups one by one.

 GitLab maps user contributions correctly when an admin access token is used to perform the import. GitLab does not map
-user contributions correctly when you are importing from a self-managed instance to GitLab.com. Correct mapping of user
-contributions when importing from a self-managed instance to GitLab.com can be preserved with paid involvement of
+user contributions correctly when you are importing from a GitLab Self-Managed instance to GitLab.com. Correct mapping of user
+contributions when importing from a GitLab Self-Managed instance to GitLab.com can be preserved with paid involvement of
 Professional Services team.

 ### Additional information
--- a/lib/authn/tokens/incoming_email_token.rb
+++ b/lib/authn/tokens/incoming_email_token.rb
@ -18,10 +18,10 @@ module Authn
        ::API::Entities::User
      end

-      def revoke!(_current_user)
+      def revoke!(current_user)
        raise ::Authn::AgnosticTokenIdentifier::NotFoundError, 'Not Found' if revocable.blank?

-        raise ::Authn::AgnosticTokenIdentifier::UnsupportedTokenError, 'Unsupported token type'
+        Users::ResetIncomingEmailTokenService.new(current_user: current_user, user: revocable).execute!
      end
    end
  end
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@ -48334,6 +48334,9 @@ msgstr ""
 msgid "Required approvals (%{approvals_given} of %{required} given, you've approved)"
 msgstr ""

+msgid "Required in this branch."
+msgstr ""
+
 msgid "Required in this project."
 msgstr ""

--- a/qa/qa/support/api.rb
+++ b/qa/qa/support/api.rb
@ -10,6 +10,7 @@ module QA
      HTTP_STATUS_NO_CONTENT = 204
      HTTP_STATUS_ACCEPTED = 202
      HTTP_STATUS_PERMANENT_REDIRECT = 308
+      HTTP_STATUS_BAD_REQUEST = 400
      HTTP_STATUS_UNAUTHORIZED = 401
      HTTP_STATUS_NOT_FOUND = 404
      HTTP_STATUS_TOO_MANY_REQUESTS = 429
--- a/qa/qa/tools/delete_resource_base.rb
+++ b/qa/qa/tools/delete_resource_base.rb
@ -89,27 +89,39 @@ module QA
      #
      # @param [<Hash>] resource
      # @param [Boolean] wait until the end of the script to verify deletion
+      # @param [Integer] max retries for unlinking security policy projects
      # @param [Hash] API call options
      # @return [Array<String, Hash>] results
-      def delete_resource(resource, delayed_verification = false, **options)
-        # If delayed deletion is not enabled, resource will be permanently deleted
-        response = delete(resource_request(resource, **options))
+      def delete_resource(resource, delayed_verification = false, max_retries = 6, **options)
+        retry_count = 0

-        if success?(response&.code) || response.include?("already marked for deletion")
-          return resource if delayed_verification
+        while retry_count <= max_retries
+          # If delayed deletion is not enabled, resource will be permanently deleted
+          response = delete(resource_request(resource, **options))

-          wait_for_resource_deletion(resource)
+          case
+          when success?(response&.code) || response.include?("already marked for deletion")
+            return resource if delayed_verification

-          return log_permanent_deletion(resource) if permanently_deleted?(resource)
+            wait_for_resource_deletion(resource)

-          return log_failure(resource, response) unless mark_for_deletion_possible?(resource)
+            return log_permanent_deletion(resource) if permanently_deleted?(resource)

-          @permanently_delete ? delete_permanently(resource) : log_marked_for_deletion(resource)
-        elsif response&.code == HTTP_STATUS_NOT_FOUND
-          log_permanent_deletion(resource)
-        else
-          log_failure(resource, response)
+            return log_failure(resource, response) unless mark_for_deletion_possible?(resource)
+
+            return @permanently_delete ? delete_permanently(resource) : log_marked_for_deletion(resource)
+          when response&.code == HTTP_STATUS_NOT_FOUND
+            return log_permanent_deletion(resource)
+          when response&.code == HTTP_STATUS_BAD_REQUEST && response&.include?("Security Policy Project")
+            if retry_count < max_retries
+              find_and_unassign_security_policy_project(resource)
+              retry_count += 1
+              next
+            end
+          end
        end
+
+        log_failure(resource, response)
      end

      def fetch_qa_user_id(qa_username)
@ -350,6 +362,45 @@ module QA
          end
        end
      end
+
+      # Finds and unassigns a security policy project from a resource
+      # Note: full_path is used for REST API resources and fullPath is used for GraphQL resources
+      # We can only unassign a security policy project through GraphQL and not the REST API.
+      #
+      # @param resource [Hash] Resource to remove security policy project from
+      # @return [void]
+      def find_and_unassign_security_policy_project(resource)
+        if has_security_policy_project?(resource)
+          unassign_security_policy_project(resource[:full_path])
+        elsif projects_with_security_policy_projects(resource).present?
+          projects_with_security_policy_projects(resource).each do |project|
+            unassign_security_policy_project(project[:fullPath])
+          end
+        elsif subgroups_with_security_policy_projects(resource).present?
+          subgroups_with_security_policy_projects(resource).each do |subgroup|
+            unassign_security_policy_project(subgroup[:fullPath])
+          end
+        end
+      end
+
+      def unassign_security_policy_project(path)
+        logger.info("Unassigning security policy project for #{path}")
+
+        mutation = <<~GQL
+          mutation {
+            securityPolicyProjectUnassign(input: { fullPath: "#{path}" }) {
+              errors
+            }
+          }
+        GQL
+
+        graphql_request(mutation)
+      end
+
+      def graphql_request(query)
+        response = post(Runtime::API::Request.new(@api_client, '/graphql').url, { query: query })
+        parse_body(response)
+      end
    end
  end
 end
--- a/qa/qa/tools/lib/group.rb
+++ b/qa/qa/tools/lib/group.rb
@ -24,6 +24,87 @@ module QA

          group[:id]
        end
+
+        def get_group_graphql(group)
+          query = <<~GRAPHQL
+            query {
+              group(fullPath: "#{group[:full_path]}") {
+                securityPolicyProject {
+                  id
+                }
+              }
+            }
+          GRAPHQL
+
+          graphql_request(query)
+        end
+
+        def get_subgroups_graphql(group)
+          query = <<~GRAPHQL
+            query {
+              group(fullPath: "#{group[:full_path]}") {
+                descendantGroups {
+                  nodes {
+                    id
+                    name
+                    fullPath
+                    securityPolicyProject {
+                      id
+                      name
+                      fullPath
+                    }
+                  }
+                }
+              }
+            }
+          GRAPHQL
+
+          graphql_request(query)
+        end
+
+        def get_group_projects_graphql(group)
+          query = <<~GRAPHQL
+            query {
+              group(fullPath: "#{group[:full_path]}") {
+                projects(includeSubgroups: true) {
+                  nodes {
+                    id
+                    name
+                    fullPath
+                    securityPolicyProject {
+                      id
+                      name
+                      fullPath
+                    }
+                  }
+                }
+              }
+            }
+          GRAPHQL
+
+          graphql_request(query)
+        end
+
+        def has_security_policy_project?(group)
+          response = get_group_graphql(group)
+          response&.dig(:data, :group, :securityPolicyProject).present?
+        end
+
+        def subgroups_with_security_policy_projects(group)
+          response = get_subgroups_graphql(group)
+          subgroups = response&.dig(:data, :group, :descendantGroups, :nodes)
+          subgroups.select do |subgroup|
+            subgroup&.dig(:securityPolicyProject).present?
+          end
+        end
+
+        def projects_with_security_policy_projects(group)
+          response = get_group_projects_graphql(group)
+          projects = response&.dig(:data, :group, :projects, :nodes)
+          projects.select do |project|
+            project&.dig(:securityPolicyProject).present?
+          end
+        end
      end
    end
  end
--- a/rubocop/formatter/todo_formatter.rb
+++ b/rubocop/formatter/todo_formatter.rb
@ -35,8 +35,6 @@ module RuboCop
        @todos = Hash.new { |hash, cop_name| hash[cop_name] = CopTodo.new(cop_name) }
        @todo_dir = TodoDir.new(directory)
        @config_inspect_todo_dir = load_config_inspect_todo_dir
-        @config_old_todo_yml = load_config_old_todo_yml
-        check_multiple_configurations!
        create_todos_retaining_exclusions(@config_inspect_todo_dir)

        super
@ -79,14 +77,6 @@ module RuboCop
        path.delete_prefix("#{parent}/")
      end

-      def check_multiple_configurations!
-        cop_names = @config_inspect_todo_dir.keys & @config_old_todo_yml.keys
-        return if cop_names.empty?
-
-        list = cop_names.sort.map { |cop_name| "- #{cop_name}" }.join("\n")
-        raise "Multiple configurations found for cops:\n#{list}\n"
-      end
-
      def create_todos_retaining_exclusions(inspected_cop_config)
        inspected_cop_config.each do |cop_name, config|
          todo = @todos[cop_name]
@ -98,7 +88,7 @@ module RuboCop
      def config_for(todo)
        cop_name = todo.cop_name

-        @config_old_todo_yml[cop_name] || @config_inspect_todo_dir[cop_name] || {}
+        @config_inspect_todo_dir[cop_name] || {}
      end

      def previously_disabled?(todo)
@ -131,15 +121,6 @@ module RuboCop
          combined.update(config) if Hash === config
        end
      end
-
-      # Load YAML configuration from `.rubocop_todo.yml`.
-      # We consider this file already old, obsolete, and to be removed soon.
-      def load_config_old_todo_yml
-        path = File.expand_path(File.join(directory, '../.rubocop_todo.yml'))
-        config = YAML.load_file(path) if File.exist?(path)
-
-        config || {}
-      end
    end
  end
 end
--- a/spec/features/merge_request/user_edits_merge_request_spec.rb
+++ b/spec/features/merge_request/user_edits_merge_request_spec.rb
@ -55,7 +55,7 @@ RSpec.describe 'User edits a merge request', :js, feature_category: :code_review
      visit(edit_project_merge_request_path(project, merge_request))

      expect(page).to have_content('Squash commits when merge request is accepted.')
-      expect(page).to have_content("Required in this project")
+      expect(page).to have_content("Required in this branch")
    end

    it 'does not display message for "Allow" project setting squash option' do
--- a/spec/frontend/design_management/components/toolbar/index_spec.js
+++ b/spec/frontend/design_management/components/toolbar/index_spec.js
@ -48,6 +48,7 @@ describe('Design management toolbar component', () => {
          name: 'Test Name',
        },
        image: '/-/designs/306/7f747adcd4693afadbe968d7ba7d983349b9012d',
+        isSidebarOpen: false,
        ...props,
      },
    });
--- a/spec/frontend/projects/new/components/snapshots/app_spec.js.snap
+++ b/spec/frontend/projects/new/components/snapshots/app_spec.js.snap
@ -4,6 +4,7 @@ exports[`Experimental new project creation app creates correct panels 1`] = `
 [
  {
    "description": "Create a blank project to store your files, plan your work, and collaborate on code, among other things.",
+    "imageSrc": "file-mock",
    "key": "blank",
    "name": "blank_project",
    "selector": "#blank-project-pane",
@ -11,6 +12,7 @@ exports[`Experimental new project creation app creates correct panels 1`] = `
  },
  {
    "description": "Create a project pre-populated with the necessary files to get you started quickly.",
+    "imageSrc": "file-mock",
    "key": "template",
    "name": "create_from_template",
    "selector": "#create-from-template-pane",
@ -18,6 +20,7 @@ exports[`Experimental new project creation app creates correct panels 1`] = `
  },
  {
    "description": "Migrate your data from an external source like GitHub, Bitbucket, or another instance of GitLab.",
+    "imageSrc": "file-mock",
    "key": "import",
    "name": "import_project",
    "selector": "#import-project-pane",
--- a/spec/frontend/work_items/components/design_management/snapshots/design_item_spec.js.snap
+++ b/spec/frontend/work_items/components/design_management/snapshots/design_item_spec.js.snap
@ -11,6 +11,7 @@ exports[`Design item component when item appears in view after image is loaded r
 exports[`Design item component with notes renders item with multiple comments 1`] = `
 <a
  class="card design-list-item gl-cursor-pointer gl-mb-0 gl-text-default hover:gl-text-default js-design-list-item"
+  href="/gitlab-org/gitlab-test/-/work_items/1/designs/test"
 >
  <div
    class="card-body gl-flex gl-items-center gl-justify-center gl-overflow-hidden gl-p-0 gl-relative gl-rounded-t-base"
@ -76,6 +77,7 @@ exports[`Design item component with notes renders item with multiple comments 1`
 exports[`Design item component with notes renders item with single comment 1`] = `
 <a
  class="card design-list-item gl-cursor-pointer gl-mb-0 gl-text-default hover:gl-text-default js-design-list-item"
+  href="/gitlab-org/gitlab-test/-/work_items/1/designs/test"
 >
  <div
    class="card-body gl-flex gl-items-center gl-justify-center gl-overflow-hidden gl-p-0 gl-relative gl-rounded-t-base"
--- a/spec/frontend/work_items/components/design_management/design_item_spec.js
+++ b/spec/frontend/work_items/components/design_management/design_item_spec.js
@ -46,6 +46,9 @@ describe('Design item component', () => {
          event,
          notesCount,
          updatedAt: '01-01-2019',
+          useRouter: true,
+          workItemWebUrl: '/gitlab-org/gitlab-test/-/work_items/1',
+          workItemIid: 'gid://gitlab/WorkItem/1',
          ...props,
        },
        data() {
@ -58,6 +61,50 @@ describe('Design item component', () => {
    );
  }

+  describe('when router navigation is possible', () => {
+    beforeEach(() => {
+      createComponent();
+    });
+
+    it('renders a router-link', () => {
+      expect(wrapper.findComponent(RouterLinkStub).exists()).toBe(true);
+    });
+
+    it('provides a valid `to` prop to the router-link', () => {
+      const routerLink = wrapper.findComponent(RouterLinkStub);
+
+      expect(routerLink.props('to')).toEqual(
+        expect.objectContaining({
+          params: {
+            id: 'test',
+            iid: 'gid://gitlab/WorkItem/1',
+          },
+        }),
+      );
+    });
+  });
+
+  describe('when router navigation is not possible', () => {
+    beforeEach(() => {
+      createComponent({
+        props: {
+          useRouter: false,
+        },
+      });
+    });
+
+    it('renders an anchor element instead of router-link', () => {
+      expect(wrapper.find('a').exists()).toBe(true);
+      expect(wrapper.findComponent(RouterLinkStub).exists()).toBe(false);
+    });
+
+    it('provides a valid `to` prop to the router-link', () => {
+      const anchor = wrapper.find('a');
+
+      expect(anchor.attributes('href')).toBe('/gitlab-org/gitlab-test/-/work_items/1/designs/test');
+    });
+  });
+
  describe('when item is not in view', () => {
    it('image is not rendered', () => {
      createComponent();
--- a/spec/frontend/work_items/components/design_management/design_management_widget_spec.js
+++ b/spec/frontend/work_items/components/design_management/design_management_widget_spec.js
@ -112,6 +112,9 @@ describe('DesignWidget', () => {
        uploadError,
        uploadErrorVariant,
        canReorderDesign,
+        workItemFullPath: 'gitlab-org/gitlab-shell',
+        workItemWebUrl: '/gitlab-org/gitlab-shell/-/work_items/1',
+        isGroup: false,
      },
      directives: {
        GlTooltip: createMockDirective('gl-tooltip'),
--- a/spec/helpers/issuables_helper_spec.rb
+++ b/spec/helpers/issuables_helper_spec.rb
@ -481,30 +481,6 @@ RSpec.describe IssuablesHelper, feature_category: :team_planning do
    end
  end

-  describe '#issuable_squash_option?' do
-    using RSpec::Parameterized::TableSyntax
-
-    where(:issuable_persisted, :squash, :squash_enabled_by_default, :expectation) do
-      true  | true  | true  | true
-      true  | false | true  | false
-      false | false | false | false
-      false | false | true  | true
-      false | true  | false | false
-      false | true  | true  | true
-    end
-
-    with_them do
-      it 'returns the correct value' do
-        project = double(
-          squash_enabled_by_default?: squash_enabled_by_default
-        )
-        issuable = double(persisted?: issuable_persisted, squash: squash)
-
-        expect(helper.issuable_squash_option?(issuable, project)).to eq(expectation)
-      end
-    end
-  end
-
  describe '#issuable_type_selector_data' do
    using RSpec::Parameterized::TableSyntax

--- a/spec/helpers/merge_requests_helper_spec.rb
+++ b/spec/helpers/merge_requests_helper_spec.rb
@ -464,4 +464,35 @@ RSpec.describe MergeRequestsHelper, feature_category: :code_review_workflow do
      expect(subject).to include(expected_data)
    end
  end
+
+  describe '#merge_request_squash_option?' do
+    using RSpec::Parameterized::TableSyntax
+
+    let(:merge_request) { build_stubbed(:merge_request) }
+
+    subject { helper.merge_request_squash_option?(merge_request) }
+
+    where(
+      :persisted, :squash, :squash_enabled_by_default, :expected
+    ) do
+      true  | true  | true  | true
+      true  | true  | false | true
+      true  | false | true  | false
+      true  | false | false | false
+      false | false | false | false
+      false | true  | false | false
+      false | false | true  | true
+      false | true  | true  | true
+    end
+
+    with_them do
+      before do
+        allow(merge_request).to receive_messages(
+          persisted?: persisted, squash: squash, squash_enabled_by_default?: squash_enabled_by_default
+        )
+      end
+
+      it { is_expected.to eq(expected) }
+    end
+  end
 end
--- a/spec/lib/authn/tokens/incoming_email_token_spec.rb
+++ b/spec/lib/authn/tokens/incoming_email_token_spec.rb
@ -2,7 +2,7 @@

 require 'spec_helper'

-RSpec.describe Authn::Tokens::IncomingEmailToken, feature_category: :system_access do
+RSpec.describe Authn::Tokens::IncomingEmailToken, :aggregate_failures, feature_category: :system_access do
  let_it_be(:user) { create(:user) }

  subject(:token) { described_class.new(plaintext, :api_admin_token) }
@ -14,10 +14,11 @@ RSpec.describe Authn::Tokens::IncomingEmailToken, feature_category: :system_acce
    it_behaves_like 'finding the valid revocable'

    describe '#revoke!' do
-      it 'does not support revocation yet' do
-        expect do
-          token.revoke!(user)
-        end.to raise_error(::Authn::AgnosticTokenIdentifier::UnsupportedTokenError, 'Unsupported token type')
+      subject(:revoke) { token.revoke!(user) }
+
+      it 'successfully resets the token' do
+        expect { revoke }.to change { user.reload.incoming_email_token }
+        expect(revoke.success?).to be_truthy
      end
    end
  end
--- a/spec/models/concerns/encrypted_user_password_spec.rb
+++ b/spec/models/concerns/encrypted_user_password_spec.rb
@ -2,7 +2,7 @@

 require 'spec_helper'

-RSpec.describe User do
+RSpec.describe User, feature_category: :system_access do
  describe '#authenticatable_salt' do
    let(:user) { build(:user, encrypted_password: encrypted_password) }

@ -53,6 +53,35 @@ RSpec.describe User do
    end

    context 'when the default encryption method is BCrypt' do
+      context 'when the user password is hashed with work factor 4' do
+        let(:encrypted_password) { "$2a$04$ThzqXSFnlW3uH86uQ79puOU7vARSFuuNzb1nUGfsBeYtCLkdymAQW" }
+        let(:increase_password_storage_stretches) { nil }
+
+        before do
+          stub_feature_flags(increase_password_storage_stretches: increase_password_storage_stretches)
+        end
+
+        context 'when feature flag is set to true' do
+          let(:increase_password_storage_stretches) { true }
+
+          it 'upgrades stretches' do
+            expect(user.encrypted_password).to start_with('$2a$04$')
+            user.valid_password?('security')
+            expect(user.encrypted_password).to start_with('$2a$05$')
+          end
+        end
+
+        context 'when feature flag is set to false' do
+          let(:increase_password_storage_stretches) { false }
+
+          it 'does not upgrade stretches' do
+            expect(user.encrypted_password).to start_with('$2a$04$')
+            user.valid_password?('security')
+            expect(user.encrypted_password).to start_with('$2a$04$')
+          end
+        end
+      end
+
      it_behaves_like 'password validation fails when the password is encrypted using an unsupported method'

      context 'when the user password PBKDF2+SHA512' do
--- a/spec/requests/api/admin/token_spec.rb
+++ b/spec/requests/api/admin/token_spec.rb
@ -198,6 +198,16 @@ RSpec.describe API::Admin::Token, :aggregate_failures, feature_category: :system
        end
      end

+      context 'when the token is an incoming email token' do
+        let(:plaintext) { user.incoming_email_token }
+
+        it 'resets the token' do
+          expect { delete_token }.to change { user.reload.incoming_email_token }
+
+          expect(response).to have_gitlab_http_status(:no_content)
+        end
+      end
+
      context 'when the revocation feature is disabled' do
        before do
          stub_feature_flags(api_admin_token_revoke: false)
--- a/spec/rubocop/formatter/graceful_formatter_spec.rb
+++ b/spec/rubocop/formatter/graceful_formatter_spec.rb
@ -7,7 +7,7 @@ require 'stringio'
 require_relative '../../../rubocop/formatter/graceful_formatter'
 require_relative '../../../rubocop/todo_dir'

-RSpec.describe RuboCop::Formatter::GracefulFormatter, :isolated_environment do
+RSpec.describe RuboCop::Formatter::GracefulFormatter, :isolated_environment, feature_category: :tooling do
  # Set by :isolated_environment
  let(:todo_dir) { RuboCop::TodoDir.new("#{Dir.pwd}/.rubocop_todo") }
  let(:stdout) { StringIO.new }
@ -43,14 +43,11 @@ RSpec.describe RuboCop::Formatter::GracefulFormatter, :isolated_environment do
    let(:offense2) { fake_offense('Cop2') }

    before do
-      FileUtils.touch('.rubocop_todo.yml')
-
      File.write('.rubocop.yml', <<~YAML)
        inherit_from:
          <% Dir.glob('.rubocop_todo/**/*.yml').each  do |rubocop_todo_yaml| %>
          - '<%= rubocop_todo_yaml %>'
          <% end  %>
-          - '.rubocop_todo.yml'

        AllCops:
          NewCops: enable # Avoiding RuboCop warnings
@ -80,7 +77,7 @@ RSpec.describe RuboCop::Formatter::GracefulFormatter, :isolated_environment do
          Details: grace period
        YAML

-        File.write('.rubocop_todo.yml', <<~YAML)
+        todo_dir.write('Cop2', <<~YAML)
        ---
        Cop2:
          Details: grace period
--- a/spec/rubocop/formatter/todo_formatter_spec.rb
+++ b/spec/rubocop/formatter/todo_formatter_spec.rb
@ -200,35 +200,6 @@ RSpec.describe RuboCop::Formatter::TodoFormatter, feature_category: :tooling do
      end
    end

-    context 'when cop previously explicitly disabled in rubocop_todo.yml' do
-      before do
-        File.write('.rubocop_todo.yml', <<~YAML)
-          ---
-          B/TooManyOffenses:
-            Enabled: false
-            Exclude:
-              - 'x.rb'
-        YAML
-
-        todo_dir.inspect_all
-      end
-
-      it 'keeps cop disabled' do
-        run_formatter
-
-        expect(todo_yml('B/TooManyOffenses')).to eq(<<~YAML)
-          ---
-          B/TooManyOffenses:
-            # Offense count: 3
-            # Temporarily disabled due to too many offenses
-            Enabled: false
-            Exclude:
-              - 'a.rb'
-              - 'c.rb'
-        YAML
-      end
-    end
-
    context 'with grace period' do
      let(:yaml) do
        <<~YAML
@ -240,6 +211,11 @@ RSpec.describe RuboCop::Formatter::TodoFormatter, feature_category: :tooling do
        YAML
      end

+      before do
+        todo_dir.write('B/TooManyOffenses', yaml)
+        todo_dir.inspect_all
+      end
+
      shared_examples 'keeps grace period' do
        it 'keeps Details: grace period' do
          run_formatter
@ -255,22 +231,7 @@ RSpec.describe RuboCop::Formatter::TodoFormatter, feature_category: :tooling do
        end
      end

-      context 'in rubocop_todo/' do
-        before do
-          todo_dir.write('B/TooManyOffenses', yaml)
-          todo_dir.inspect_all
-        end
-
-        it_behaves_like 'keeps grace period'
-      end
-
-      context 'in rubocop_todo.yml' do
-        before do
-          File.write('.rubocop_todo.yml', yaml)
-        end
-
-        it_behaves_like 'keeps grace period'
-      end
+      it_behaves_like 'keeps grace period'

      context 'with invalid details value' do
        let(:yaml) do
@ -284,8 +245,6 @@ RSpec.describe RuboCop::Formatter::TodoFormatter, feature_category: :tooling do
        end

        it 'ignores the details and warns' do
-          File.write('.rubocop_todo.yml', yaml)
-
          expect { run_formatter }
            .to output(%r{B/TooManyOffenses: Unhandled value "something unknown" for `Details` key.})
            .to_stderr
@ -313,51 +272,11 @@ RSpec.describe RuboCop::Formatter::TodoFormatter, feature_category: :tooling do
        end

        it 'raises an exception' do
-          File.write('.rubocop_todo.yml', yaml)
-
          expect { run_formatter }
            .to raise_error(RuntimeError, 'B/TooManyOffenses: Cop must be enabled to use `Details: grace period`.')
        end
      end
    end
-
-    context 'with cop configuration in both .rubocop_todo/ and .rubocop_todo.yml' do
-      before do
-        todo_dir.write('B/TooManyOffenses', <<~YAML)
-          ---
-          B/TooManyOffenses:
-            Exclude:
-              - 'a.rb'
-        YAML
-
-        todo_dir.write('A/Offense', <<~YAML)
-          ---
-          A/Offense:
-            Exclude:
-              - 'a.rb'
-        YAML
-
-        todo_dir.inspect_all
-
-        File.write('.rubocop_todo.yml', <<~YAML)
-          ---
-          B/TooManyOffenses:
-            Exclude:
-              - 'x.rb'
-          A/Offense:
-            Exclude:
-              - 'y.rb'
-        YAML
-      end
-
-      it 'raises an error' do
-        expect { run_formatter }.to raise_error(RuntimeError, <<~TXT)
-          Multiple configurations found for cops:
-          - A/Offense
-          - B/TooManyOffenses
-        TXT
-      end
-    end
  end

  context 'without offenses detected' do
--- a/spec/services/users/reset_incoming_email_token_service_spec.rb
+++ b/spec/services/users/reset_incoming_email_token_service_spec.rb
@ -0,0 +1,46 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe Users::ResetIncomingEmailTokenService, feature_category: :system_access do
+  shared_examples_for 'a successfully reset token' do
+    it { expect(execute.success?).to be true }
+    it { expect { execute }.to change { user.incoming_email_token } }
+  end
+
+  shared_examples_for 'an unsuccessfully reset token' do
+    it { expect(execute.success?).to be false }
+    it { expect { execute }.not_to change { user.incoming_email_token } }
+  end
+
+  describe '#execute!' do
+    let(:service) { described_class.new(current_user: current_user, user: user) }
+
+    let_it_be(:existing_user) { create(:user) }
+
+    subject(:execute) { service.execute! }
+
+    context 'when current_user is an admin', :enable_admin_mode do
+      let(:current_user) { create(:admin) }
+      let(:user) { existing_user }
+
+      it_behaves_like 'a successfully reset token'
+    end
+
+    context 'when current_user is not an administrator' do
+      let(:current_user) { existing_user }
+
+      context 'when user is a different user' do
+        let(:user) { create(:user) }
+
+        it_behaves_like 'an unsuccessfully reset token'
+      end
+
+      context 'when user is current_user' do
+        let(:user) { current_user }
+
+        it_behaves_like 'a successfully reset token'
+      end
+    end
+  end
+end
--- a/spec/tasks/rubocop_rake_spec.rb
+++ b/spec/tasks/rubocop_rake_spec.rb
@ -12,7 +12,7 @@ require_relative '../../rubocop/formatter/todo_formatter'
 require_relative '../../rubocop/todo_dir'
 require_relative '../../rubocop/check_graceful_task'

-RSpec.describe 'rubocop rake tasks', :silence_stdout do
+RSpec.describe 'rubocop rake tasks', :silence_stdout, feature_category: :tooling do
  include NextInstanceOf

  before do
@ -81,14 +81,13 @@ RSpec.describe 'rubocop rake tasks', :silence_stdout do

      RUBY

-      # Mimicking GitLab's .rubocop_todo.yml avoids relying on RuboCop's
+      # Mimicking GitLab's .rubocop_todo/**/*.yml avoids relying on RuboCop's
      # default.yml configuration.
      File.write('.rubocop.yml', <<~YAML)
        <% unless  ENV['REVEAL_RUBOCOP_TODO'] == '1' %>
          <% Dir.glob('.rubocop_todo/**/*.yml').each  do |rubocop_todo_yaml| %>
        - '<%= rubocop_todo_yaml %>'
          <% end  %>
-        - '.rubocop_todo.yml'
        <% end  %>

        AllCops:
@ -107,16 +106,6 @@ RSpec.describe 'rubocop rake tasks', :silence_stdout do
          Enabled: true
      YAML

-      # Required to verify that we are revealing all TODOs via
-      # ENV['REVEAL_RUBOCOP_TODO'] = '1'.
-      # This file can be removed from specs after we've moved all offenses from
-      # .rubocop_todo.yml to .rubocop_todo/**/*.yml.
-      File.write('.rubocop_todo.yml', <<~YAML)
-        # Too many offenses
-        Layout/SpaceAroundOperators:
-          Enabled: false
-      YAML
-
      # Previous offense now fixed.
      todo_dir.write('Lint/Syntax', '')
    end
--- a/spec/tooling/danger/project_helper_spec.rb
+++ b/spec/tooling/danger/project_helper_spec.rb
@ -90,7 +90,6 @@ RSpec.describe Tooling::Danger::ProjectHelper, feature_category: :tooling do
      'lib/foo'                    | [:backend]
      'rubocop/foo'                | [:backend]
      '.rubocop.yml'               | [:backend]
-      '.rubocop_todo.yml'          | [:backend]
      '.rubocop_todo/cop/name.yml' | [:backend]
      'gems/foo/.rubocop.yml'      | [:backend]
      'spec/foo'                   | [:backend]
--- a/spec/workers/pages/reset_pages_default_domain_redirect_worker_spec.rb
+++ b/spec/workers/pages/reset_pages_default_domain_redirect_worker_spec.rb
@ -4,12 +4,13 @@ require 'spec_helper'

 RSpec.describe Pages::ResetPagesDefaultDomainRedirectWorker, feature_category: :pages do
  let_it_be_with_reload(:project) { create(:project) }
+  let_it_be(:primary_domain_url_with_scheme) { 'https://primary.domain.com' }
  let_it_be(:primary_domain_url) { 'primary.domain.com' }
  let_it_be(:non_primary_domain_url) { 'non-primary.domain.com' }
  let_it_be(:primary_domain) { create(:pages_domain, project: project, domain: primary_domain_url) }
  let_it_be(:non_primary_domain) { create(:pages_domain, project: project, domain: non_primary_domain_url) }
  let_it_be(:project_setting) do
-    create(:project_setting, project: project, pages_primary_domain: primary_domain_url)
+    create(:project_setting, project: project, pages_primary_domain: primary_domain_url_with_scheme)
  end

  let(:event) do
@ -33,7 +34,7 @@ RSpec.describe Pages::ResetPagesDefaultDomainRedirectWorker, feature_category: :

      expect { use_event }
        .to change { project.reload.project_setting.pages_primary_domain }
-              .from(primary_domain_url).to(nil)
+              .from(primary_domain_url_with_scheme).to(nil)
    end
  end

--- a/spec/workers/repository_update_remote_mirror_worker_spec.rb
+++ b/spec/workers/repository_update_remote_mirror_worker_spec.rb
@ -12,10 +12,6 @@ RSpec.describe RepositoryUpdateRemoteMirrorWorker, :clean_gitlab_redis_shared_st
    freeze_time { example.run }
  end

-  before do
-    stub_feature_flags(remote_mirror_retry_with_delay: false)
-  end
-
  def expect_mirror_service_to_return(mirror, result, tries = 0)
    expect_next_instance_of(Projects::UpdateRemoteMirrorService) do |service|
      expect(service).to receive(:execute).with(mirror, tries).and_return(result)
@ -45,27 +41,21 @@ RSpec.describe RepositoryUpdateRemoteMirrorWorker, :clean_gitlab_redis_shared_st

      expect(described_class)
        .to receive(:perform_in)
-              .with(remote_mirror.backoff_delay, remote_mirror.id, scheduled_time, 1)
+              .with(remote_mirror.backoff_delay, remote_mirror.id, kind_of(Time), 1)

      subject.perform(remote_mirror.id, scheduled_time)
    end

-    context 'when remote_mirror_retry_with_delay feature flag is enabled' do
-      before do
-        stub_feature_flags(remote_mirror_retry_with_delay: true)
-      end
+    it 'continues scheduling retries after successive failures' do
+      remote_mirror.update_start!
+      remote_mirror.hard_retry!('Error!')
+      expect_mirror_service_to_return(remote_mirror, { status: :error, message: 'Retry!' }, 1)

-      it 'continues scheduling retries after successive failures' do
-        remote_mirror.update_start!
-        remote_mirror.hard_retry!('Error!')
-        expect_mirror_service_to_return(remote_mirror, { status: :error, message: 'Retry!' }, 1)
+      expect(described_class)
+        .to receive(:perform_in)
+        .with(remote_mirror.backoff_delay, remote_mirror.id, retry_time, 2)

-        expect(described_class)
-          .to receive(:perform_in)
-          .with(remote_mirror.backoff_delay, remote_mirror.id, retry_time, 2)
-
-        subject.perform(remote_mirror.id, Time.current, 1)
-      end
+      subject.perform(remote_mirror.id, Time.current, 1)
    end

    it 'clears the lease if there was an unexpected exception' do
--- a/tooling/danger/project_helper.rb
+++ b/tooling/danger/project_helper.rb
@ -144,7 +144,7 @@ module Tooling
        %r{\A((ee|jh)/)?vendor/} => :backend,
        %r{\A(Gemfile.*|Rakefile)\z} => :backend,
        %r{\A[A-Z_]+_VERSION\z} => :backend,
-        %r{\A\.rubocop(_todo)?\.yml\z} => :backend,
+        %r{\A\.rubocop\.yml\z} => :backend,
        %r{\Agems/.*/\.rubocop\.yml\z} => :backend,
        %r{\A\.rubocop_todo/.*\.yml\z} => :backend,
        %r{\Afile_hooks/} => :backend,
				`@ -0,0 +1 @@`
				`2811c9c9cd1e4a6c2bedc1eea17856d48e7de2e64c9db4bc1217681a1ac5a152`