Add latest changes from gitlab-org/gitlab@master

2022-04-27 18:10:15 +00:00 · 2022-04-27 18:10:15 +00:00 · 6093748e9e
parent 6d82b3a0c5
commit 6093748e9e
105 changed files with 1001 additions and 410 deletions
--- a/.gitlab/ci/review-apps/qa.gitlab-ci.yml
+++ b/.gitlab/ci/review-apps/qa.gitlab-ci.yml
@ -16,6 +16,7 @@ include:
  variables:
    QA_DEBUG: "true"
    QA_CAN_TEST_GIT_PROTOCOL_V2: "false"
+    QA_CAN_TEST_PRAEFECT: "false"
    QA_GENERATE_ALLURE_REPORT: "true"
    GITLAB_USERNAME: "root"
    GITLAB_PASSWORD: "${REVIEW_APPS_ROOT_PASSWORD}"
--- a/4
+++ b/4
@ -4,7 +4,7 @@ source 'https://rubygems.org'

 gem 'rails', '~> 6.1.4.7'

-gem 'bootsnap', '~> 1.9.1', require: false
+gem 'bootsnap', '~> 1.9.4', require: false

 # Responders respond_to and respond_with
 gem 'responders', '~> 3.0'
@ -543,4 +543,4 @@ gem 'ipaddress', '~> 0.8.3'

 gem 'parslet', '~> 1.8'

-gem 'ipynbdiff', '0.4.5'
+gem 'ipynbdiff', '0.4.6'
--- a/Gemfile.lock
+++ b/Gemfile.lock
@ -150,7 +150,7 @@ GEM
      rack (>= 0.9.0)
    bindata (2.4.10)
    binding_ninja (0.2.3)
-    bootsnap (1.9.1)
+    bootsnap (1.9.4)
      msgpack (~> 1.0)
    bootstrap_form (4.2.0)
      actionpack (>= 5.0)
@ -665,7 +665,7 @@ GEM
    invisible_captcha (1.1.0)
      rails (>= 4.2)
    ipaddress (0.8.3)
-    ipynbdiff (0.4.5)
+    ipynbdiff (0.4.6)
      diffy (~> 3.3)
      json (~> 2.5, >= 2.5.1)
    jaeger-client (1.1.0)
@ -784,7 +784,7 @@ GEM
      faraday (>= 0.9, < 2.0.0)
      faraday-cookie_jar (~> 0.0.6)
      ms_rest (~> 0.7.6)
-    msgpack (1.3.3)
+    msgpack (1.5.1)
    multi_json (1.14.1)
    multi_xml (0.6.0)
    multipart-post (2.1.1)
@ -1447,7 +1447,7 @@ DEPENDENCIES
  benchmark-ips (~> 2.3.0)
  benchmark-memory (~> 0.1)
  better_errors (~> 2.9.0)
-  bootsnap (~> 1.9.1)
+  bootsnap (~> 1.9.4)
  bootstrap_form (~> 4.2.0)
  browser (~> 4.2)
  bullet (~> 6.1.3)
@ -1548,7 +1548,7 @@ DEPENDENCIES
  icalendar
  invisible_captcha (~> 1.1.0)
  ipaddress (~> 0.8.3)
-  ipynbdiff (= 0.4.5)
+  ipynbdiff (= 0.4.6)
  jira-ruby (~> 2.1.4)
  js_regex (~> 3.7)
  json (~> 2.5.1)
--- a/app/assets/javascripts/pipelines/components/pipeline_tabs.vue
+++ b/app/assets/javascripts/pipelines/components/pipeline_tabs.vue
@ -1,6 +1,7 @@
 <script>
 import { GlTabs, GlTab } from '@gitlab/ui';
 import { __ } from '~/locale';
+import { failedJobsTabName, jobsTabName, needsTabName, testReportTabName } from '../constants';
 import PipelineGraphWrapper from './graph/graph_component_wrapper.vue';
 import Dag from './dag/dag.vue';
 import JobsApp from './jobs/jobs_app.vue';
@ -16,6 +17,12 @@ export default {
      testsTitle: __('Tests'),
    },
  },
+  tabNames: {
+    needs: needsTabName,
+    jobs: jobsTabName,
+    failures: failedJobsTabName,
+    tests: testReportTabName,
+  },
  components: {
    Dag,
    GlTab,
@ -25,24 +32,47 @@ export default {
    PipelineGraphWrapper,
    TestReports,
  },
+  inject: ['defaultTabValue'],
+  methods: {
+    isActive(tabName) {
+      return tabName === this.defaultTabValue;
+    },
+  },
 };
 </script>

 <template>
  <gl-tabs>
-    <gl-tab :title="$options.i18n.tabs.pipelineTitle" data-testid="pipeline-tab">
+    <gl-tab ref="pipelineTab" :title="$options.i18n.tabs.pipelineTitle" data-testid="pipeline-tab">
      <pipeline-graph-wrapper />
    </gl-tab>
-    <gl-tab :title="$options.i18n.tabs.needsTitle" data-testid="dag-tab">
+    <gl-tab
+      ref="dagTab"
+      :title="$options.i18n.tabs.needsTitle"
+      :active="isActive($options.tabNames.needs)"
+      data-testid="dag-tab"
+    >
      <dag />
    </gl-tab>
-    <gl-tab :title="$options.i18n.tabs.jobsTitle" data-testid="jobs-tab">
+    <gl-tab
+      :title="$options.i18n.tabs.jobsTitle"
+      :active="isActive($options.tabNames.jobs)"
+      data-testid="jobs-tab"
+    >
      <jobs-app />
    </gl-tab>
-    <gl-tab :title="$options.i18n.tabs.failedJobsTitle" data-testid="failed-jobs-tab">
+    <gl-tab
+      :title="$options.i18n.tabs.failedJobsTitle"
+      :active="isActive($options.tabNames.failures)"
+      data-testid="failed-jobs-tab"
+    >
      <failed-jobs-app />
    </gl-tab>
-    <gl-tab :title="$options.i18n.tabs.testsTitle" data-testid="tests-tab">
+    <gl-tab
+      :title="$options.i18n.tabs.testsTitle"
+      :active="isActive($options.tabNames.tests)"
+      data-testid="tests-tab"
+    >
      <test-reports />
    </gl-tab>
    <slot></slot>
--- a/app/assets/javascripts/pipelines/constants.js
+++ b/app/assets/javascripts/pipelines/constants.js
@ -45,6 +45,28 @@ export const UNSUPPORTED_DATA = 'unsupported_data';

 export const CHILD_VIEW = 'child';

+// Pipeline tabs
+
+export const TAB_QUERY_PARAM = 'tab';
+
+export const needsTabName = 'dag';
+export const jobsTabName = 'builds';
+export const failedJobsTabName = 'failures';
+export const testReportTabName = 'test_report';
+export const securityTabName = 'security';
+export const licensesTabName = 'licenses';
+export const codeQualityTabName = 'codequality_report';
+
+export const validPipelineTabNames = [
+  needsTabName,
+  jobsTabName,
+  failedJobsTabName,
+  testReportTabName,
+  securityTabName,
+  licensesTabName,
+  codeQualityTabName,
+];
+
 // Constants for the ID and IID selection dropdown
 export const PipelineKeyOptions = [
  {
--- a/app/assets/javascripts/pipelines/pipeline_tabs.js
+++ b/app/assets/javascripts/pipelines/pipeline_tabs.js
@ -1,7 +1,9 @@
 import Vue from 'vue';
 import VueApollo from 'vue-apollo';
 import PipelineTabs from 'ee_else_ce/pipelines/components/pipeline_tabs.vue';
-import { reportToSentry } from './utils';
+import { removeParams, updateHistory } from '~/lib/utils/url_utility';
+import { TAB_QUERY_PARAM } from '~/pipelines/constants';
+import { getPipelineDefaultTab, reportToSentry } from './utils';

 Vue.use(VueApollo);

@ -18,6 +20,15 @@ const createPipelineTabs = (selector, apolloProvider) => {
    exposeSecurityDashboard,
    exposeLicenseScanningData,
  } = dataset;
+
+  const defaultTabValue = getPipelineDefaultTab(window.location.href);
+
+  updateHistory({
+    url: removeParams([TAB_QUERY_PARAM]),
+    title: document.title,
+    replace: true,
+  });
+
  // eslint-disable-next-line no-new
  new Vue({
    el: selector,
@ -28,6 +39,7 @@ const createPipelineTabs = (selector, apolloProvider) => {
    provide: {
      canGenerateCodequalityReports: JSON.parse(canGenerateCodequalityReports),
      codequalityReportDownloadPath,
+      defaultTabValue,
      downloadablePathForReportType,
      exposeSecurityDashboard: JSON.parse(exposeSecurityDashboard),
      exposeLicenseScanningData: JSON.parse(exposeLicenseScanningData),
--- a/app/assets/javascripts/pipelines/utils.js
+++ b/app/assets/javascripts/pipelines/utils.js
@ -1,7 +1,12 @@
 import * as Sentry from '@sentry/browser';
 import { pickBy } from 'lodash';
-import { SUPPORTED_FILTER_PARAMETERS, NEEDS_PROPERTY } from './constants';
-
+import { getParameterValues } from '~/lib/utils/url_utility';
+import {
+  NEEDS_PROPERTY,
+  SUPPORTED_FILTER_PARAMETERS,
+  TAB_QUERY_PARAM,
+  validPipelineTabNames,
+} from './constants';
 /*
    The following functions are the main engine in transforming the data as
    received from the endpoint into the format the d3 graph expects.
@ -138,3 +143,13 @@ export const reportMessageToSentry = (component, message, context) => {
    Sentry.captureMessage(message);
  });
 };
+
+export const getPipelineDefaultTab = (url) => {
+  const [tabQueryValue] = getParameterValues(TAB_QUERY_PARAM, url);
+
+  if (tabQueryValue && validPipelineTabNames.includes(tabQueryValue)) {
+    return tabQueryValue;
+  }
+
+  return null;
+};
--- a/app/controllers/groups/imports_controller.rb
+++ b/app/controllers/groups/imports_controller.rb
@ -4,6 +4,7 @@ class Groups::ImportsController < Groups::ApplicationController
  include ContinueParams

  feature_category :importers
+  urgency :low

  def show
    if @group.import_state.nil? || @group.import_state.finished?
--- a/app/controllers/groups_controller.rb
+++ b/app/controllers/groups_controller.rb
@ -57,6 +57,7 @@ class GroupsController < Groups::ApplicationController
  feature_category :code_review, [:merge_requests, :unfoldered_environment_names]
  feature_category :projects, [:projects]
  feature_category :importers, [:export, :download_export]
+  urgency :low, [:export, :download_export]

  urgency :high, [:unfoldered_environment_names]

--- a/app/controllers/import/available_namespaces_controller.rb
+++ b/app/controllers/import/available_namespaces_controller.rb
@ -2,6 +2,7 @@

 class Import::AvailableNamespacesController < ApplicationController
  feature_category :importers
+  urgency :low

  def index
    render json: NamespaceSerializer.new.represent(current_user.manageable_groups_with_routes(include_groups_with_developer_maintainer_access: true))
--- a/app/controllers/import/base_controller.rb
+++ b/app/controllers/import/base_controller.rb
@ -5,6 +5,7 @@ class Import::BaseController < ApplicationController

  before_action -> { check_rate_limit!(:project_import, scope: [current_user, :project_import], redirect_back: true) }, only: [:create]
  feature_category :importers
+  urgency :low

  def status
    respond_to do |format|
--- a/app/controllers/import/bulk_imports_controller.rb
+++ b/app/controllers/import/bulk_imports_controller.rb
@ -7,6 +7,7 @@ class Import::BulkImportsController < ApplicationController
  before_action :verify_blocked_uri, only: :status

  feature_category :importers
+  urgency :low

  POLLING_INTERVAL = 3_000

--- a/app/controllers/import/gitlab_groups_controller.rb
+++ b/app/controllers/import/gitlab_groups_controller.rb
@ -6,6 +6,7 @@ class Import::GitlabGroupsController < ApplicationController
  before_action :check_import_rate_limit!, only: %i[create]

  feature_category :importers
+  urgency :low

  def create
    unless file_is_valid?(group_params[:file])
--- a/app/controllers/import/history_controller.rb
+++ b/app/controllers/import/history_controller.rb
@ -2,4 +2,5 @@

 class Import::HistoryController < ApplicationController
  feature_category :importers
+  urgency :low
 end
--- a/app/controllers/import/url_controller.rb
+++ b/app/controllers/import/url_controller.rb
@ -2,6 +2,7 @@

 class Import::UrlController < ApplicationController
  feature_category :importers
+  urgency :low

  def validate
    result = Import::ValidateRemoteGitEndpointService.new(validate_params).execute
--- a/app/controllers/projects/imports_controller.rb
+++ b/app/controllers/projects/imports_controller.rb
@ -12,6 +12,7 @@ class Projects::ImportsController < Projects::ApplicationController
  before_action :redirect_if_no_import, only: :show

  feature_category :importers
+  urgency :low

  def new
  end
--- a/app/controllers/projects/issues_controller.rb
+++ b/app/controllers/projects/issues_controller.rb
@ -69,6 +69,7 @@ class Projects::IssuesController < Projects::ApplicationController
  feature_category :service_desk, [:service_desk]
  urgency :low, [:service_desk]
  feature_category :importers, [:import_csv, :export_csv]
+  urgency :low, [:import_csv, :export_csv]

  attr_accessor :vulnerability_id

--- a/app/controllers/projects/pipelines_controller.rb
+++ b/app/controllers/projects/pipelines_controller.rb
@ -149,12 +149,22 @@ class Projects::PipelinesController < Projects::ApplicationController
  end

  def builds
-    render_show
+    if Feature.enabled?(:pipeline_tabs_vue, project, default_enabled: :yaml)
+      redirect_to pipeline_path(@pipeline, tab: 'builds')
+    else
+      render_show
+    end
  end

  def dag
    respond_to do |format|
-      format.html { render_show }
+      format.html do
+        if Feature.enabled?(:pipeline_tabs_vue, project, default_enabled: :yaml)
+          redirect_to pipeline_path(@pipeline, tab: 'dag')
+        else
+          render_show
+        end
+      end
      format.json do
        render json: Ci::DagPipelineSerializer
          .new(project: @project, current_user: @current_user)
@ -164,7 +174,9 @@ class Projects::PipelinesController < Projects::ApplicationController
  end

  def failures
-    if @pipeline.failed_builds.present?
+    if Feature.enabled?(:pipeline_tabs_vue, project, default_enabled: :yaml)
+      redirect_to pipeline_path(@pipeline, tab: 'failures')
+    elsif @pipeline.failed_builds.present?
      render_show
    else
      redirect_to pipeline_path(@pipeline)
@ -218,7 +230,13 @@ class Projects::PipelinesController < Projects::ApplicationController

  def test_report
    respond_to do |format|
-      format.html { render_show }
+      format.html do
+        if Feature.enabled?(:pipeline_tabs_vue, project, default_enabled: :yaml)
+          redirect_to pipeline_path(@pipeline, tab: 'test_report')
+        else
+          render_show
+        end
+      end
      format.json do
        render json: TestReportSerializer
          .new(current_user: @current_user)
--- a/app/controllers/projects_controller.rb
+++ b/app/controllers/projects_controller.rb
@ -56,6 +56,7 @@ class ProjectsController < Projects::ApplicationController
  feature_category :code_review, [:unfoldered_environment_names]
  feature_category :portfolio_management, [:planning_hierarchy]

+  urgency :low, [:export, :remove_export, :generate_new_export, :download_export]
  # TODO: Set high urgency for #show https://gitlab.com/gitlab-org/gitlab/-/issues/334444
  urgency :low, [:refs, :show, :toggle_star, :transfer, :archive, :destroy, :update]
  urgency :high, [:unfoldered_environment_names]
--- a/app/models/environment.rb
+++ b/app/models/environment.rb
@ -26,7 +26,7 @@ class Environment < ApplicationRecord
  has_many :self_managed_prometheus_alert_events, inverse_of: :environment
  has_many :alert_management_alerts, class_name: 'AlertManagement::Alert', inverse_of: :environment

-  has_one :last_deployment, -> { Feature.enabled?(:env_last_deployment_by_finished_at, default_enabled: :yaml) ? success.ordered : success.distinct_on_environment }, class_name: 'Deployment', inverse_of: :environment
+  has_one :last_deployment, -> { success.ordered }, class_name: 'Deployment', inverse_of: :environment
  has_one :last_visible_deployment, -> { visible.distinct_on_environment }, inverse_of: :environment, class_name: 'Deployment'
  has_one :last_visible_deployable, through: :last_visible_deployment, source: 'deployable', source_type: 'CommitStatus', disable_joins: true
  has_one :last_visible_pipeline, through: :last_visible_deployable, source: 'pipeline', disable_joins: true
--- a/app/models/member.rb
+++ b/app/models/member.rb
@ -77,6 +77,10 @@ class Member < ApplicationRecord
    ]).merge(self)
  end

+  scope :excluding_users, ->(user_ids) do
+    where.not(user_id: user_ids)
+  end
+
  # This scope encapsulates (most of) the conditions a row in the member table
  # must satisfy if it is a valid permission. Of particular note:
  #
--- a/config/feature_flags/development/env_last_deployment_by_finished_at.yml
+++ b/config/feature_flags/development/env_last_deployment_by_finished_at.yml
@ -1,8 +0,0 @@
---
-name: env_last_deployment_by_finished_at
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83558
-rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/357299
-milestone: '14.10'
-type: development
-group: group::release
-default_enabled: true
--- a/db/docs/abuse_reports.yml
+++ b/db/docs/abuse_reports.yml
@ -3,7 +3,7 @@ table_name: abuse_reports
 classes:
 - AbuseReport
 feature_categories:
- users
-description: TODO
+- instance_resiliency
+description: Stores abuse reports from other users.
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/cba7f20dc8614d12e3eeda6e14f454aeb22b9b54
 milestone: '7.13'
--- a/db/docs/analytics_cycle_analytics_project_value_streams.yml
+++ b/db/docs/analytics_cycle_analytics_project_value_streams.yml
@ -3,7 +3,7 @@ table_name: analytics_cycle_analytics_project_value_streams
 classes:
 - Analytics::CycleAnalytics::ProjectValueStream
 feature_categories:
- planning_analytics
-description: TODO
+- value_stream_management
+description: Used to store the value stream configurations for projects
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60925
 milestone: '13.12'
--- a/db/docs/board_assignees.yml
+++ b/db/docs/board_assignees.yml
@ -4,6 +4,6 @@ classes:
 - BoardAssignee
 feature_categories:
 - team_planning
-description: TODO
+description: Used by issue boards to filter issues by assignee as part of the default scope
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2912
 milestone: '10.2'
--- a/db/docs/board_group_recent_visits.yml
+++ b/db/docs/board_group_recent_visits.yml
@ -4,6 +4,6 @@ classes:
 - BoardGroupRecentVisit
 feature_categories:
 - team_planning
-description: TODO
+description: The last group issue board visited by a user, used to redirect them from the default boards page
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/7aeab58f4861144fcc1d334907cb1b465c645001
 milestone: '11.5'
--- a/db/docs/board_labels.yml
+++ b/db/docs/board_labels.yml
@ -4,6 +4,6 @@ classes:
 - BoardLabel
 feature_categories:
 - team_planning
-description: TODO
+description: Used by issue boards to filter issues by label as part of the default scope
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2912
 milestone: '10.2'
--- a/db/docs/board_project_recent_visits.yml
+++ b/db/docs/board_project_recent_visits.yml
@ -4,6 +4,6 @@ classes:
 - BoardProjectRecentVisit
 feature_categories:
 - team_planning
-description: TODO
+description: The last project issue board visited by a user, used to redirect them from the default boards page
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/7aeab58f4861144fcc1d334907cb1b465c645001
 milestone: '11.5'
--- a/db/docs/board_user_preferences.yml
+++ b/db/docs/board_user_preferences.yml
@ -4,6 +4,6 @@ classes:
 - BoardUserPreference
 feature_categories:
 - team_planning
-description: TODO
+description: Preferences for issue boards stored on a per user basis, such as whether to hide or show labels
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33892
 milestone: '13.1'
--- a/db/docs/boards_epic_board_labels.yml
+++ b/db/docs/boards_epic_board_labels.yml
@ -3,7 +3,7 @@ table_name: boards_epic_board_labels
 classes:
 - Boards::EpicBoardLabel
 feature_categories:
- team_planning
-description: TODO
+- portfolio_management
+description: Information relating epic boards to labels used to scope the boards
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48658
 milestone: '13.7'
--- a/db/docs/boards_epic_board_positions.yml
+++ b/db/docs/boards_epic_board_positions.yml
@ -3,7 +3,7 @@ table_name: boards_epic_board_positions
 classes:
 - Boards::EpicBoardPosition
 feature_categories:
- team_planning
-description: TODO
+- portfolio_management
+description: Relates epics to epic boards by position, unique to each combination of epic and board
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/48120
 milestone: '13.7'
--- a/db/docs/boards_epic_board_recent_visits.yml
+++ b/db/docs/boards_epic_board_recent_visits.yml
@ -3,7 +3,7 @@ table_name: boards_epic_board_recent_visits
 classes:
 - Boards::EpicBoardRecentVisit
 feature_categories:
- team_planning
-description: TODO
+- portfolio_management
+description: The epic board most recently visited by users, used to determine where to redirect them by default
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60720
 milestone: '13.12'
--- a/db/docs/boards_epic_list_user_preferences.yml
+++ b/db/docs/boards_epic_list_user_preferences.yml
@ -3,7 +3,7 @@ table_name: boards_epic_list_user_preferences
 classes:
 - Boards::EpicListUserPreference
 feature_categories:
- team_planning
-description: TODO
+- portfolio_management
+description: Epic board list preferences on a per-user basis, specifically whether the user has collapsed the list or not
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54541
 milestone: '13.10'
--- a/db/docs/boards_epic_user_preferences.yml
+++ b/db/docs/boards_epic_user_preferences.yml
@ -3,7 +3,7 @@ table_name: boards_epic_user_preferences
 classes:
 - Boards::EpicUserPreference
 feature_categories:
- team_planning
-description: TODO
+- portfolio_management
+description: The epic_ids used to create swimlanes on issue boards; stored per user, per board
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40360
 milestone: '13.4'
--- a/db/docs/chat_names.yml
+++ b/db/docs/chat_names.yml
@ -3,7 +3,8 @@ table_name: chat_names
 classes:
 - ChatName
 feature_categories:
- users
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/c60437786bfe43344b4a5eb040437f73f37c6396
+- integrations
+- chatops
+description: Stores mappings from external chat accounts to GitLab users.
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7450
 milestone: '8.14'
--- a/db/docs/chat_teams.yml
+++ b/db/docs/chat_teams.yml
@ -3,7 +3,8 @@ table_name: chat_teams
 classes:
 - ChatTeam
 feature_categories:
- users
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/297dc70158f905fef4557d1ee6510bcf459a08a9
+- integrations
+- chatops
+description: Stores mappings from external chat teams to GitLab groups.
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8746
 milestone: '9.0'
--- a/db/docs/commit_user_mentions.yml
+++ b/db/docs/commit_user_mentions.yml
@ -3,7 +3,7 @@ table_name: commit_user_mentions
 classes:
 - CommitUserMention
 feature_categories:
- users
-description: TODO
+- team_planning
+description: User mentions in commit messages 
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19009
 milestone: '12.6'
--- a/db/docs/custom_emoji.yml
+++ b/db/docs/custom_emoji.yml
@ -4,6 +4,6 @@ classes:
 - CustomEmoji
 feature_categories:
 - team_planning
-description: TODO
+description: Filename and name of custom emoji created by users
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24229
 milestone: '13.2'
--- a/db/docs/customer_relations_contacts.yml
+++ b/db/docs/customer_relations_contacts.yml
@ -3,7 +3,7 @@ table_name: customer_relations_contacts
 classes:
 - CustomerRelations::Contact
 feature_categories:
- users
-description: TODO
+- service_desk
+description: Contacts, against which time can be spent by users on issues using the CRM functionality
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67985
 milestone: '14.3'
--- a/db/docs/customer_relations_organizations.yml
+++ b/db/docs/customer_relations_organizations.yml
@ -3,7 +3,7 @@ table_name: customer_relations_organizations
 classes:
 - CustomerRelations::Organization
 feature_categories:
- subgroups
-description: TODO
+- team_planning
+description: Organizations, against which time can be spent by users on issues using the CRM functionality
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67551
 milestone: '14.2'
--- a/db/docs/draft_notes.yml
+++ b/db/docs/draft_notes.yml
@ -3,9 +3,8 @@ table_name: draft_notes
 classes:
 - DraftNote
 feature_categories:
- projects
+- code_review
 - source_code_management
- team_planning
-description: TODO
+description: Notes created during the review of an MR that are not yet published
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4213
 milestone: '11.4'
--- a/db/docs/epic_user_mentions.yml
+++ b/db/docs/epic_user_mentions.yml
@ -3,7 +3,7 @@ table_name: epic_user_mentions
 classes:
 - EpicUserMention
 feature_categories:
- users
-description: TODO
+- team_planning
+description: User mentions in epic descriptions
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19009
 milestone: '12.6'
--- a/db/docs/group_crm_settings.yml
+++ b/db/docs/group_crm_settings.yml
@ -3,7 +3,7 @@ table_name: group_crm_settings
 classes:
 - Group::CrmSettings
 feature_categories:
- subgroups
-description: TODO
+- service_desk
+description: Group-level settings for CRM-related features
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76983
 milestone: '14.7'
--- a/db/docs/group_features.yml
+++ b/db/docs/group_features.yml
@ -3,7 +3,7 @@ table_name: group_features
 classes:
 - Groups::FeatureSetting
 feature_categories:
- subgroups
-description: TODO
+- navigation
+description: Stores access levels for group features, like the wiki
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82017
 milestone: '14.10'
--- a/db/docs/internal_ids.yml
+++ b/db/docs/internal_ids.yml
@ -3,8 +3,7 @@ table_name: internal_ids
 classes:
 - InternalId
 feature_categories:
- projects
- subgroups
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/754272e392c0da088200a1b56156600973f63267
+- database
+description: Keeps track of counters scoped to a certain context, e.g. a project-wide counter for issues.
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17580
 milestone: '10.7'
--- a/db/docs/issuable_severities.yml
+++ b/db/docs/issuable_severities.yml
@ -4,6 +4,6 @@ classes:
 - IssuableSeverity
 feature_categories:
 - team_planning
-description: TODO
+description: Integer representing severity applied to issues, currently used for incidents
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/40272
 milestone: '13.4'
--- a/db/docs/issue_assignees.yml
+++ b/db/docs/issue_assignees.yml
@ -4,6 +4,6 @@ classes:
 - IssueAssignee
 feature_categories:
 - team_planning
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/ac5d8fddd6809113e3d43d94c315f993605135e9
+description: Users assigned to an issue
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1541
 milestone: '9.2'
--- a/db/docs/issue_emails.yml
+++ b/db/docs/issue_emails.yml
@ -3,7 +3,8 @@ table_name: issue_emails
 classes:
 - Issue::Email
 feature_categories:
+- service_desk
 - team_planning
-description: TODO
+description: The Message-ID of the original email that resulted in the creation of an issue
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71749
 milestone: '14.6'
--- a/db/docs/issue_links.yml
+++ b/db/docs/issue_links.yml
@ -4,6 +4,6 @@ classes:
 - IssueLink
 feature_categories:
 - team_planning
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/7afdb31770f927cf4fcca98ab675e015f39f8479
+description: Links two issues by relationship type, which can be related or blocking
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1719
 milestone: '9.4'
--- a/db/docs/issue_user_mentions.yml
+++ b/db/docs/issue_user_mentions.yml
@ -4,6 +4,6 @@ classes:
 - IssueUserMention
 feature_categories:
 - team_planning
-description: TODO
+description: User mentions in issue descriptions
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/19009
 milestone: '12.6'
--- a/db/docs/issues.yml
+++ b/db/docs/issues.yml
@ -5,6 +5,6 @@ classes:
 - WorkItem
 feature_categories:
 - team_planning
-description: TODO
+description: Information describing issues, which is also used by the WorkItem class
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/9ba1224867665844b117fa037e1465bb706b3685
 milestone: "<6.0"
--- a/db/docs/iterations_cadences.yml
+++ b/db/docs/iterations_cadences.yml
@ -4,6 +4,6 @@ classes:
 - Iterations::Cadence
 feature_categories:
 - team_planning
-description: TODO
+description: Defines an iteration cadence for a group, used to define how iterations should act
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50707
-milestone: '13.10'
+milestone: '13.9'
--- a/db/docs/keys.yml
+++ b/db/docs/keys.yml
@ -5,7 +5,8 @@ classes:
 - Key
 - LDAPKey
 feature_categories:
- users
-description: TODO
+- authentication_and_authorization
+- continuous_delivery
+description: SSH keys used by users or for deployments.
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/9ba1224867665844b117fa037e1465bb706b3685
 milestone: "<6.0"
--- a/db/docs/label_links.yml
+++ b/db/docs/label_links.yml
@ -4,6 +4,6 @@ classes:
 - LabelLink
 feature_categories:
 - team_planning
-description: TODO
+description: Information linking labels with target objects that can be labelled; such as issues, MRs and epics
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/03654a6abf47c88b8b980a6707874ff78080d2fe
 milestone: '7.2'
--- a/db/docs/label_priorities.yml
+++ b/db/docs/label_priorities.yml
@ -4,6 +4,6 @@ classes:
 - LabelPriority
 feature_categories:
 - team_planning
-description: TODO
+description: The relative priority assigned to a label within a project, if any
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/297892011330ecdd2fa7cbe47fbc6fd4f3b62171
-milestone: '8.13'
+milestone: '8.14'
--- a/db/docs/labels.yml
+++ b/db/docs/labels.yml
@ -6,6 +6,6 @@ classes:
 - ProjectLabel
 feature_categories:
 - team_planning
-description: TODO
+description: Information related to labels, which can be associated with groups or projects
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/03654a6abf47c88b8b980a6707874ff78080d2fe
 milestone: '7.2'
--- a/db/docs/list_user_preferences.yml
+++ b/db/docs/list_user_preferences.yml
@ -3,7 +3,7 @@ table_name: list_user_preferences
 classes:
 - ListUserPreference
 feature_categories:
- users
-description: TODO
+- team_planning
+description: Issue board list preferences on a per-user basis, specifically whether the user has collapsed the list or not
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/15657
 milestone: '12.3'
--- a/db/docs/milestones.yml
+++ b/db/docs/milestones.yml
@ -4,6 +4,6 @@ classes:
 - Milestone
 feature_categories:
 - team_planning
-description: TODO
+description: Information related to milestones, used by team planning features to timebox work
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/23d950855d6d2524d00b1f0618c008e2529f06a4
 milestone: "<6.0"
--- a/db/docs/namespace_admin_notes.yml
+++ b/db/docs/namespace_admin_notes.yml
@ -3,7 +3,8 @@ table_name: namespace_admin_notes
 classes:
 - Namespace::AdminNote
 feature_categories:
+- authentication_and_authorization
 - subgroups
-description: TODO
+description: Contains notes about groups that are visible to server administrators.
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/47825
 milestone: '13.11'
--- a/db/docs/namespace_limits.yml
+++ b/db/docs/namespace_limits.yml
@ -3,7 +3,7 @@ table_name: namespace_limits
 classes:
 - NamespaceLimit
 feature_categories:
- subgroups
-description: TODO
+- utilization
+description: Contains limits for namespace features like storage and ci
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34746
 milestone: '13.2'
--- a/db/docs/notes.yml
+++ b/db/docs/notes.yml
@ -12,7 +12,11 @@ classes:
 - SyntheticNote
 - WeightNote
 feature_categories:
+- code_review
+- portfolio_management
+- service_desk
+- snippets
 - team_planning
-description: TODO
+description: The object at the core of comments, discussions and system notes shown on issues, MRs and epics
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/9ba1224867665844b117fa037e1465bb706b3685
 milestone: "<6.0"
--- a/db/docs/notification_settings.yml
+++ b/db/docs/notification_settings.yml
@ -4,6 +4,6 @@ classes:
 - NotificationSetting
 feature_categories:
 - team_planning
-description: TODO
+description: User preferences for receiving notifications related to various actions within the application
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/31b0e53015e38e51d9c02cca85c9279600b1bf85
 milestone: '8.7'
--- a/db/docs/programming_languages.yml
+++ b/db/docs/programming_languages.yml
@ -3,7 +3,7 @@ table_name: programming_languages
 classes:
 - ProgrammingLanguage
 feature_categories:
- projects
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/79a5d76801a45696db629e1f543f2e1d6fa4784f
+- source_code_management
+description: Contains known programming languages and their assigned colors
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19480
 milestone: '11.2'
--- a/db/docs/project_ci_feature_usages.yml
+++ b/db/docs/project_ci_feature_usages.yml
@ -3,8 +3,7 @@ table_name: project_ci_feature_usages
 classes:
 - Projects::CiFeatureUsage
 feature_categories:
- projects
- continuous_integration
-description: TODO
+- code_testing
+description: Project CI feature usage information
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68186
 milestone: '14.2'
--- a/db/docs/project_features.yml
+++ b/db/docs/project_features.yml
@ -3,7 +3,7 @@ table_name: project_features
 classes:
 - ProjectFeature
 feature_categories:
- projects
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/892dea67717c0efbd6a28f7639f34535ec0a8747
+- navigation
+description: Stores access levels for project features like wikis, issues, repositories, containers, ect.
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/5606
 milestone: '8.12'
--- a/db/docs/project_security_settings.yml
+++ b/db/docs/project_security_settings.yml
@ -3,7 +3,8 @@ table_name: project_security_settings
 classes:
 - ProjectSecuritySetting
 feature_categories:
- projects
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/9af97ee69a36de1dc4e73f4030d6316d3f0a82c5
+- dependency_scanning
+- container_scanning
+description: Project settings related to security features.
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/32577
 milestone: '13.1'
--- a/db/docs/project_tracing_settings.yml
+++ b/db/docs/project_tracing_settings.yml
@ -3,7 +3,7 @@ table_name: project_tracing_settings
 classes:
 - ProjectTracingSetting
 feature_categories:
- projects
+- tracing
 description: TODO
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7903
 milestone: '11.5'
--- a/db/docs/resource_iteration_events.yml
+++ b/db/docs/resource_iteration_events.yml
@ -4,6 +4,6 @@ classes:
 - ResourceIterationEvent
 feature_categories:
 - planning_analytics
-description: TODO
+description: Records the addition and removal of issues to iterations
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37617
 milestone: '13.3'
--- a/db/docs/resource_label_events.yml
+++ b/db/docs/resource_label_events.yml
@ -4,6 +4,6 @@ classes:
 - ResourceLabelEvent
 feature_categories:
 - planning_analytics
-description: TODO
+description: Records the addition and removal of labels from resources that can be labelled; such as issues, MRs and epics
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6697
 milestone: '11.2'
--- a/db/docs/resource_milestone_events.yml
+++ b/db/docs/resource_milestone_events.yml
@ -3,7 +3,7 @@ table_name: resource_milestone_events
 classes:
 - ResourceMilestoneEvent
 feature_categories:
- team_planning
-description: TODO
+- planning_analytics
+description: Records the addition and removal of issues to milestones
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23965
 milestone: '12.8'
--- a/db/docs/resource_state_events.yml
+++ b/db/docs/resource_state_events.yml
@ -3,7 +3,7 @@ table_name: resource_state_events
 classes:
 - ResourceStateEvent
 feature_categories:
- team_planning
-description: TODO
+- planning_analytics
+description: Records the change of state of issues between opened and closed
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28926
 milestone: '13.0'
--- a/db/docs/resource_weight_events.yml
+++ b/db/docs/resource_weight_events.yml
@ -3,7 +3,7 @@ table_name: resource_weight_events
 classes:
 - ResourceWeightEvent
 feature_categories:
- team_planning
-description: TODO
+- planning_analytics
+description: Records the change of weight on issues along with timestamps
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21515
 milestone: '12.7'
--- a/db/docs/saved_replies.yml
+++ b/db/docs/saved_replies.yml
@ -3,7 +3,7 @@ table_name: saved_replies
 classes:
 - Users::SavedReply
 feature_categories:
- users
-description: TODO
+- team_planning
+description: Text templates used to populate comments using a quick action
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80807
 milestone: '14.9'
--- a/db/docs/sent_notifications.yml
+++ b/db/docs/sent_notifications.yml
@ -3,7 +3,7 @@ table_name: sent_notifications
 classes:
 - SentNotification
 feature_categories:
- users
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/f76eac56b9d7d4ae61010cddcca68682824b2239
+- team_planning
+description: Information related to sent email notifications that supports reply-by-email functionality
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/1173
 milestone: '8.0'
--- a/db/docs/sprints.yml
+++ b/db/docs/sprints.yml
@ -4,6 +4,6 @@ classes:
 - Iteration
 feature_categories:
 - team_planning
-description: TODO
+description: Also called iterations, timeboxes to which issues can be assigned. Used to plan and track work.
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/30125
 milestone: '13.0'
--- a/db/docs/timelogs.yml
+++ b/db/docs/timelogs.yml
@ -4,6 +4,6 @@ classes:
 - Timelog
 feature_categories:
 - team_planning
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/bf13fa054a67d5245ee83555e730d7ee6ab7264c
+description: Time spend data recorded by users on issues
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/870
 milestone: '8.14'
--- a/db/docs/todos.yml
+++ b/db/docs/todos.yml
@ -4,6 +4,6 @@ classes:
 - Todo
 feature_categories:
 - team_planning
-description: TODO
+description: An action required or notification of action taken for a user on a target object, generated by various actions within the GitLab application
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/3d52e139b13ad077286f2f9f46b7e98f43ad9564
 milestone: '8.5'
--- a/db/docs/user_callouts.yml
+++ b/db/docs/user_callouts.yml
@ -5,5 +5,5 @@ classes:
 feature_categories:
 - users
 description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/648826721f13ee4309a11638e538d96006648b39
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/16735
 milestone: '10.5'
--- a/db/docs/user_canonical_emails.yml
+++ b/db/docs/user_canonical_emails.yml
@ -3,7 +3,7 @@ table_name: user_canonical_emails
 classes:
 - UserCanonicalEmail
 feature_categories:
- users
-description: TODO
-introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/commit/9af97ee69a36de1dc4e73f4030d6316d3f0a82c5
+- authentication_and_authorization
+description: stores the canonical version of user's primary email address
+introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27722
 milestone: '13.0'
--- a/db/docs/user_credit_card_validations.yml
+++ b/db/docs/user_credit_card_validations.yml
@ -3,7 +3,7 @@ table_name: user_credit_card_validations
 classes:
 - Users::CreditCardValidation
 feature_categories:
- users
-description: TODO
+- purchase
+description: Stores whether the user has completed a first time validation to run CI pipelines
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60626
 milestone: '13.12'
--- a/db/docs/work_item_types.yml
+++ b/db/docs/work_item_types.yml
@ -4,6 +4,6 @@ classes:
 - WorkItems::Type
 feature_categories:
 - team_planning
-description: TODO
+description: The work item type related to an issue. Currently one of a predefined set but in future will support custom types.
 introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/55705
 milestone: '14.2'
--- a/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
+++ b/doc/administration/geo/disaster_recovery/runbooks/planned_failover_single_node.md
@ -85,22 +85,22 @@ follow these steps to avoid unnecessary data loss:
   **primary**. Your **secondary** site still needs read-only
   access to the **primary** site during the maintenance window:

-   1. At the scheduled time, using your cloud provider or your node's firewall, block
-      all HTTP, HTTPS and SSH traffic to/from the **primary** node, **except** for your IP and
-      the **secondary** node's IP.
+   1. At the scheduled time, using your cloud provider or your site's firewall, block
+      all HTTP, HTTPS and SSH traffic to/from the **primary** site, **except** for your IP and
+      the **secondary** site's IP.

-      For instance, you can run the following commands on the **primary** node:
+      For instance, you can run the following commands on the **primary** site:

      ```shell
-      sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 22 -j ACCEPT
+      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 22 -j ACCEPT
      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 22 -j ACCEPT
      sudo iptables -A INPUT --destination-port 22 -j REJECT

-      sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 80 -j ACCEPT
+      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 80 -j ACCEPT
      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 80 -j ACCEPT
      sudo iptables -A INPUT --tcp-dport 80 -j REJECT

-      sudo iptables -A INPUT -p tcp -s <secondary_node_ip> --destination-port 443 -j ACCEPT
+      sudo iptables -A INPUT -p tcp -s <secondary_site_ip> --destination-port 443 -j ACCEPT
      sudo iptables -A INPUT -p tcp -s <your_ip> --destination-port 443 -j ACCEPT
      sudo iptables -A INPUT --tcp-dport 443 -j REJECT
      ```
@ -142,7 +142,7 @@ follow these steps to avoid unnecessary data loss:
         those with `geo` in the name to drop to 0.
         These queues contain work that has been submitted by your users; failing over
         before it is completed, causes the work to be lost.
-      1. On the left sidebar, select **Geo > Nodes** and wait for the
+      1. On the left sidebar, select **Geo > Sites** and wait for the
         following conditions to be true of the **secondary** site you are failing over to:

         - All replication meters reach 100% replicated, 0% failures.
@ -224,15 +224,15 @@ Note the following when promoting a secondary:

 To promote the secondary site running GitLab 14.5 and later:

-1. SSH in to your **secondary** node and run one of the following commands:
+1. SSH in to your **secondary** site and run one of the following commands:

-   - To promote the secondary node to primary:
+   - To promote the secondary site to primary:

     ```shell
     sudo gitlab-ctl geo promote
     ```

-   - To promote the secondary node to primary **without any further confirmation**:
+   - To promote the secondary site to primary **without any further confirmation**:

     ```shell
     sudo gitlab-ctl geo promote --force
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@ -1344,6 +1344,27 @@ To stop `systemd` from cleaning the Pages related content:
   sudo gitlab-ctl restart gitlab-pages
   ```

+### Unable to access GitLab Pages
+
+If you can't access your GitLab Pages (such as receiving `502 Bad Gateway` errors, or a login loop)
+and in your Pages log shows this error:
+
+```plaintext
+"error":"retrieval context done: context deadline exceeded","host":"root.docs-cit.otenet.gr","level":"error","msg":"could not fetch domain information from a source"
+```
+
+1. Add the following to `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   gitlab_pages['internal_gitlab_server'] = 'http://localhost:8080'
+   ```
+
+1. Restart GitLab Pages:
+
+   ```shell
+   sudo gitlab-ctl restart gitlab-pages
+   ```
+
 ### 404 error after promoting a Geo secondary to a primary node

 Pages files are not among the
--- a/doc/development/fips_compliance.md
+++ b/doc/development/fips_compliance.md
@ -97,3 +97,321 @@ virtual machine:
 ```shell
 fips-mode-setup --disable
 ```
+
+## Set up a FIPS-enabled cluster
+
+You can use the [GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to spin
+up a FIPS-enabled cluster for development and testing. These instructions use Amazon Web Services (AWS)
+because that is the first target environment, but you can adapt them for other providers.
+
+### Set up your environment
+
+To get started, your AWS account must subscribe to a FIPS-enabled Amazon
+Machine Image (AMI) in the [AWS Marketplace console](https://aws.amazon.com/premiumsupport/knowledge-center/launch-ec2-marketplace-subscription/).
+
+This example assumes that the `Ubuntu Pro 20.04 FIPS LTS` AMI by
+`Canonical Group Limited` has been added your account. This operating
+system is used for virtual machines running in Amazon EC2.
+
+### Omnibus
+
+The simplest way to get a FIPS-enabled GitLab cluster is to use an Omnibus reference architecture.
+See the [GET Quick Start Guide](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/docs/environment_quick_start_guide.md)
+for more details. The following instructions build on the Quick Start and are also necessary for [Cloud Native Hybrid](#cloud-native-hybrid) installations.
+
+#### Terraform: Use a FIPS AMI
+
+1. Follow the guide to set up Terraform and Ansible.
+1. After [step 2b](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/-/blob/main/docs/environment_quick_start_guide.md#2b-setup-config),
+   create a `data.tf` in your environment (for example, `gitlab-environment-toolkit/terraform/environments/gitlab-10k/inventory/data.tf`):
+
+   ```tf
+   data "aws_ami" "ubuntu_20_04_fips" {
+     count = 1
+
+     most_recent = true
+
+     filter {
+       name   = "name"
+       values = ["ubuntu-pro-fips-server/images/hvm-ssd/ubuntu-focal-20.04-amd64-pro-fips-server-*"]
+     }
+
+     filter {
+       name   = "virtualization-type"
+       values = ["hvm"]
+     }
+
+     owners = ["aws-marketplace"]
+   }
+   ```
+
+1. Add the custom `ami_id` to use this AMI in `environment.tf`. For
+   example, in `gitlab-environment-toolkit/terraform/environments/gitlab-10k/inventory/environment.tf`:
+
+   ```tf
+   module "gitlab_ref_arch_aws" {
+     source = "../../modules/gitlab_ref_arch_aws"
+
+     prefix = var.prefix
+     ami_id = data.aws_ami.ubuntu_20_04_fips[0].id
+     ...
+   ```
+
+NOTE:
+GET does not allow the AMI to change on EC2 instances after it has
+been deployed via `terraform apply`. Since an AMI change would tear down
+an instance, this would result in data loss: not only would disks be
+destroyed, but also GitLab secrets would be lost. There is a [Terraform lifecycle rule](https://gitlab.com/gitlab-org/gitlab-environment-toolkit/blob/2aaeaff8ac8067f23cd7b6bb5bf131061649089d/terraform/modules/gitlab_aws_instance/main.tf#L40)
+to ignore AMI changes.
+
+#### Ansible: Specify the FIPS Omnibus builds
+
+The standard Omnibus GitLab releases build their own OpenSSL library,
+which is not FIPS-validated. However, we have nightly builds that create
+Omnibus packages that link against the operating system's OpenSSL library. To
+use this package, update the `gitlab_repo_script_url` field in the
+Ansible `vars.yml`. For example, you might modify
+`gitlab-environment-toolkit/ansible/environments/gitlab-10k/inventory/vars.yml`
+in this way:
+
+```yaml
+all:
+  vars:
+    ...
+    gitlab_repo_script_url: "https://packages.gitlab.com/install/repositories/gitlab/nightly-fips-builds/script.deb.sh"
+```
+
+### Cloud Native Hybrid
+
+A Cloud Native Hybrid install uses both Omnibus and Cloud Native GitLab
+(CNG) images. The previous instructions cover the Omnibus part, but two
+additional steps are needed to enable FIPS in CNG:
+
+1. Use a custom Amazon Elastic Kubernetes Service (EKS) AMI.
+1. Use GitLab containers built with RedHat's Universal Base Image (UBI).
+
+#### Build a custom EKS AMI
+
+Because Amazon does not yet publish a FIPS-enabled AMI, you have to
+build one yourself with Packer.
+
+Amazon publishes the following Git repositories with information about custom EKS AMIs:
+
+- [Amazon EKS AMI Build Specification](https://github.com/awslabs/amazon-eks-ami)
+- [Sample EKS custom AMIs](https://github.com/aws-samples/amazon-eks-custom-amis/)
+
+This [GitHub pull request](https://github.com/awslabs/amazon-eks-ami/pull/898) makes
+it possible to create an Amazon Linux 2 EKS AMI with FIPS enabled for Kubernetes v1.21.
+To build an image:
+
+1. [Install Packer](https://learn.hashicorp.com/tutorials/packer/get-started-install-cli).
+1. Run the following:
+
+   ```shell
+   git clone https://github.com/awslabs/amazon-eks-ami
+   cd amazon-eks-ami
+   git fetch origin pull/898/head:fips-ami
+   git checkout fips-ami
+   AWS_DEFAULT_REGION=us-east-1 make 1.21-fips # Be sure to set the region accordingly
+   ```
+
+If you are using a different version of Kubernetes, adjust the `make`
+command and `Makefile` accordingly.
+
+When the AMI build is done, a new AMI should be created with a message
+such as the following:
+
+```plaintext
+==> Builds finished. The artifacts of successful builds are:
+--> amazon-ebs: AMIs were created:
+us-west-2: ami-0a25e760cd00b027e
+```
+
+In this example, the AMI ID is `ami-0a25e760cd00b027e`, but your value may
+be different.
+
+Building a RHEL-based system with FIPS enabled should be possible, but
+there is [an outstanding issue preventing the Packer build from completing](https://github.com/aws-samples/amazon-eks-custom-amis/issues/51).
+
+#### Terraform: Use a custom EKS AMI
+
+Now you can set the custom EKS AMI.
+
+1. In `environment.tf`, add `eks_ami_id = var.eks_ami_id` so you can pass this variable to the
+   AWS reference architecture module. For example, in
+   `gitlab-environment-toolkit/terraform/environments/gitlab-10k/inventory/environment.tf`:
+
+   ```tf
+   module "gitlab_ref_arch_aws" {
+     source = "../../modules/gitlab_ref_arch_aws"
+
+     prefix = var.prefix
+     ami_id = data.aws_ami.ubuntu_20_04_fips[0].id
+     eks_ami_id = var.eks_ami_id
+     ....
+   ```
+
+1. In `variables.tf`, define a `eks_ami_id` with the AMI ID in the
+   previous step:
+
+   ```tf
+   variable "eks_ami_id" {
+     default = "ami-0a25e760cd00b027e"
+   }
+   ```
+
+#### Ansible: Use UBI images
+
+CNG uses a Helm Chart to manage which container images to deploy. By default, GET
+deploys the latest released versions that use Debian-based containers.
+
+To switch to UBI-based containers, edit the Ansible `vars.yml` to use custom
+Charts variables:
+
+```yaml
+all:
+  vars:
+    ...
+    gitlab_charts_custom_config_file: '/path/to/gitlab-environment-toolkit/ansible/environments/gitlab-10k/inventory/charts.yml'
+```
+
+Now create `charts.yml` in the location specified above and specify tags with a `-ubi8` suffix. For example:
+
+```yaml
+global:
+  image:
+    pullPolicy: Always
+  certificates:
+    image:
+      tag: master-ubi8
+
+gitlab:
+  gitaly:
+    image:
+      tag: master-ubi8
+  gitlab-exporter:
+    image:
+      tag: master-ubi8
+  gitlab-shell:
+    image:
+      tag: main-ubi8 # The default branch is main, not master
+  gitlab-mailroom:
+    image:
+      tag: master-ubi8
+  migrations:
+    image:
+      tag: master-ubi8
+  sidekiq:
+    image:
+      tag: master-ubi8
+  toolbox:
+    image:
+      tag: master-ubi8
+  webservice:
+    image:
+      tag: master-ubi8
+    workhorse:
+      tag: master-ubi8
+
+nginx-ingress:
+  controller:
+    image:
+      repository: registry.gitlab.com/stanhu/gitlab-test-images/k8s-staging-ingress-nginx/controller
+      tag: v1.2.0-beta.1
+      pullPolicy: Always
+      digest: sha256:ace38833689ad34db4a46bc1e099242696eb800def88f02200a8615530734116
+```
+
+The above example shows a FIPS-enabled [`nginx-ingress`](https://github.com/kubernetes/ingress-nginx) image.
+See [this issue](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3153#note_917782207) for more details on
+how to build NGINX and the Ingress Controller.
+
+You can also use release tags, but the versioning is tricky because each
+component may use its own versioning scheme. For example, for GitLab v14.10:
+
+```yaml
+global:
+  certificates:
+    image:
+      tag: 20191127-r2-ubi8
+
+gitlab:
+  gitaly:
+    image:
+      tag: v14.10.0-ubi8
+  gitlab-exporter:
+    image:
+      tag: 11.14.0-ubi8
+  gitlab-shell:
+    image:
+      tag: v13.25.1-ubi8
+  gitlab-mailroom:
+    image:
+      tag: v14.10.0-ubi8
+  migrations:
+    image:
+      tag: v14.10.0-ubi8
+  sidekiq:
+    image:
+      tag: v14.10.0-ubi8
+  toolbox:
+    image:
+      tag: v14.10.0-ubi8
+  webservice:
+    image:
+      tag: v14.10.0-ubi8
+    workhorse:
+      tag: v14.10.0-ubi8
+```
+
+## Verify FIPS
+
+The following sections describe ways you can verify if FIPS is enabled.
+
+### Kernel
+
+```shell
+$ cat /proc/sys/crypto/fips_enabled
+1
+```
+
+### Ruby (Omnibus images)
+
+```ruby
+$ /opt/gitlab/embedded/bin/irb
+irb(main):001:0> require 'openssl'; OpenSSL.fips_mode
+=> true
+```
+
+### Ruby (CNG images)
+
+```ruby
+$ irb
+irb(main):001:0> require 'openssl'; OpenSSL.fips_mode
+=> true
+```
+
+### Go
+
+Google maintains a [`dev.boringcrypto` branch](https://github.com/golang/go/tree/dev.boringcrypto) in the Golang compiler
+that makes it possible to statically link BoringSSL, a FIPS-validated module forked from OpenSSL.
+However, BoringSSL is not intended for public use.
+
+We use [a fork of the `dev.boringcrypto` branch](https://github.com/golang-fips/go) to build Go programs that
+dynamically link OpenSSL via `dlopen`. We can check whether a given
+binary is using OpenSSL via `go tool nm` and look for symbols named
+`Cfunc__goboringcrypto`. For example:
+
+```plaintext
+$ go tool nm nginx-ingress-controller  | grep Cfunc__goboringcrypto | tail
+ 2a0b650 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Final
+ 2a0b658 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Init
+ 2a0b660 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA384_Update
+ 2a0b668 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Final
+ 2a0b670 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Init
+ 2a0b678 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_SHA512_Update
+ 2a0b680 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_sign
+ 2a0b688 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ECDSA_verify
+ 2a0b690 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_error_string_n
+ 2a0b698 D crypto/internal/boring._cgo_71ae3cd1ca33_Cfunc__goboringcrypto_internal_ERR_get_error
+```
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@ -679,7 +679,7 @@ The confidence ranges from `Low` to `Confirmed`, but it can also be `Unknown`,
 Valid values are: `Ignore`, `Unknown`, `Experimental`, `Low`, `Medium`, `High`, or `Confirmed`

 `Unknown` values means that data is unavailable to determine it's actual value. Therefore, it may be `high`, `medium`, or `low`,
-and needs to be investigated. We have [provided a chart](../../user/application_security/sast/analyzers.md#analyzers-data)
+and needs to be investigated. We have [provided a chart](../../user/application_security/sast/analyzers.md#data-provided-by-analyzers)
 of the available SAST Analyzers and what data is currently available.

 #### Remediations
--- a/doc/update/index.md
+++ b/doc/update/index.md
@ -321,7 +321,7 @@ Find where your version sits in the upgrade path below, and upgrade GitLab
 accordingly, while also consulting the
 [version-specific upgrade instructions](#version-specific-upgrading-instructions):

-`8.11.Z` -> `8.12.0` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> [`11.11.8`](#1200) -> `12.0.12` -> [`12.1.17`](#1210) -> [`12.10.14`](#12100) -> `13.0.14` -> [`13.1.11`](#1310) -> [`13.8.8`](#1388) -> [`13.12.15`](#13120) -> [`14.0.12`](#1400) -> [latest `14.Y.Z`](https://gitlab.com/gitlab-org/gitlab/-/releases)
+`8.11.Z` -> `8.12.0` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> [`11.11.8`](#1200) -> `12.0.12` -> [`12.1.17`](#1210) -> [`12.10.14`](#12100) -> `13.0.14` -> [`13.1.11`](#1310) -> [`13.8.8`](#1388) -> [`13.12.15`](#13120) -> [`14.0.12`](#1400) -> [`14.9.0`](#1490) -> [latest `14.Y.Z`](https://gitlab.com/gitlab-org/gitlab/-/releases)

 The following table, while not exhaustive, shows some examples of the supported
 upgrade paths.
@ -398,6 +398,23 @@ NOTE:
 Specific information that follow related to Ruby and Git versions do not apply to [Omnibus installations](https://docs.gitlab.com/omnibus/)
 and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with appropriate Ruby and Git versions and are not using system binaries for Ruby and Git. There is no need to install Ruby or Git when utilizing these two approaches.

+### 14.9.0
+
+- Database changes made by the upgrade to GitLab 14.9 can take hours or days to complete on larger GitLab instances. 
+  These [batched background migrations](#batched-background-migrations) update whole database tables to ensure corresponding
+  records in `namespaces` table for each record in `projects` table.
+
+  After you update to 14.9.0 or a later 14.9 patch version,
+  [batched background migrations need to finish](#batched-background-migrations)
+  before you update to a later version.
+
+  If the migrations are not finished and you try to update to a later version,
+  you'll see an error like:
+
+  ```plaintext
+  Expected batched background migration for the given configuration to be marked as 'finished', but it is 'active':
+  ```
+
 ### 14.8.0

 - If upgrading from a version earlier than 14.6.5, 14.7.4, or 14.8.2, please review the [Critical Security Release: 14.8.2, 14.7.4, and 14.6.5](https://about.gitlab.com/releases/2022/02/25/critical-security-release-gitlab-14-8-2-released/) blog post.
--- a/doc/user/application_security/sast/analyzers.md
+++ b/doc/user/application_security/sast/analyzers.md
@ -4,20 +4,25 @@ group: Static Analysis
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---

-# SAST Analyzers **(FREE)**
+# SAST analyzers **(FREE)**

 > [Moved](https://gitlab.com/groups/gitlab-org/-/epics/2098) from GitLab Ultimate to GitLab Free in 13.3.

-SAST relies on underlying third party tools that are wrapped into what we call
-"Analyzers". An analyzer is a
-[dedicated project](https://gitlab.com/gitlab-org/security-products/analyzers)
-that wraps a particular tool to:
+Static Application Security Testing (SAST) uses analyzers
+to detect vulnerabilities in source code. Each analyzer is a wrapper around a [scanner](../terminology/#scanner), a third-party code analysis tool.

- Expose its detection logic.
- Handle its execution.
- Convert its output to the common format.
+The analyzers are published as Docker images that SAST uses to launch dedicated containers for each
+analysis.

-This is achieved by implementing the [common API](https://gitlab.com/gitlab-org/security-products/analyzers/common).
+SAST default images are maintained by GitLab, but you can also integrate your own custom image.
+
+For each scanner, an analyzer:
+
+- Exposes its detection logic.
+- Handles its execution.
+- Converts its output to a [standard format](../terminology/#secure-report-format).
+
+## SAST analyzers

 SAST supports the following official analyzers:

@ -36,12 +41,6 @@ SAST supports the following official analyzers:
 - [`sobelow`](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow) (Sobelow (Elixir Phoenix))
 - [`spotbugs`](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) (SpotBugs with the Find Sec Bugs plugin (Ant, Gradle and wrapper, Grails, Maven and wrapper, SBT))

-The analyzers are published as Docker images that SAST uses to launch
-dedicated containers for each analysis.
-
-SAST is pre-configured with a set of **default images** that are maintained by
-GitLab, but users can also integrate their own **custom images**.
-
 ## SAST analyzer features

 For an analyzer to be considered Generally Available, it is expected to minimally
@ -55,97 +54,22 @@ support the following features:
 - [Emits JSON report format](index.md#reports-json-format)
 - [SELinux support](index.md#running-sast-in-selinux)

-## Official default analyzers
+## Post analyzers

-Any custom change to the official analyzers can be achieved by using a
-[CI/CD variable in your `.gitlab-ci.yml`](index.md#available-cicd-variables).
+Post analyzers enrich the report output by an analyzer. A post analyzer doesn't modify report
+content directly. Instead, it enhances the results with additional properties, including:

-### Using a custom Docker mirror
+- CWEs.
+- Location tracking fields.
+- A means of identifying false positives or insignificant findings. **(ULTIMATE)**

-You can switch to a custom Docker registry that provides the official analyzer
-images under a different prefix. For instance, the following instructs
-SAST to pull `my-docker-registry/gl-images/sast/bandit`
-instead of `registry.gitlab.com/security-products/sast/bandit`.
-In `.gitlab-ci.yml` define:
+## Data provided by analyzers

-```yaml
-include:
-  - template: Security/SAST.gitlab-ci.yml
+Each analyzer provides data about the vulnerabilities it detects. The following table details the
+data available from each analyzer. The values provided by these tools are heterogeneous so they are sometimes
+normalized into common values, for example, `severity` and `confidence`.

-variables:
-  SECURE_ANALYZERS_PREFIX: my-docker-registry/gl-images
-```
-
-This configuration requires that your custom registry provides images for all
-the official analyzers.
-
-### Disabling all default analyzers
-
-Setting `SAST_DISABLED` to `true` disables all the official
-default analyzers. In `.gitlab-ci.yml` define:
-
-```yaml
-include:
-  - template: Security/SAST.gitlab-ci.yml
-
-variables:
-  SAST_DISABLED: true
-```
-
-That's needed when one totally relies on [custom analyzers](#custom-analyzers).
-
-### Disabling specific default analyzers
-
-Set `SAST_EXCLUDED_ANALYZERS` to a comma-delimited string that includes the official
-default analyzers that you want to avoid running. In `.gitlab-ci.yml` define the
-following to prevent the `eslint` analyzer from running:
-
-```yaml
-include:
-  - template: Security/SAST.gitlab-ci.yml
-
-variables:
-  SAST_EXCLUDED_ANALYZERS: "eslint"
-```
-
-## Post Analyzers **(ULTIMATE)**
-
-While analyzers are thin wrappers for executing scanners, post analyzers work to
-enrich the data generated within our reports.
-
-GitLab SAST post analyzers never modify report contents directly but work by
-augmenting results with additional properties (such as CWEs), location tracking fields,
-and a means of identifying false positives or insignificant findings.
-
-The implementation of post analyzers is determined by feature availability tiers, where
-simple data enrichment may occur within our free tier and most advanced processing is split
-into separate binaries or pipeline jobs.
-
-## Custom Analyzers
-
-You can provide your own analyzers by
-defining CI jobs in your CI configuration. For consistency, you should suffix your custom
-SAST jobs with `-sast`. Here's how to add a scanning job that's based on the
-Docker image `my-docker-registry/analyzers/csharp` and generates a SAST report
-`gl-sast-report.json` when `/analyzer run` is executed. Define the following in
-`.gitlab-ci.yml`:
-
-```yaml
-csharp-sast:
-  image:
-    name: "my-docker-registry/analyzers/csharp"
-  script:
-    - /analyzer run
-  artifacts:
-    reports:
-      sast: gl-sast-report.json
-```
-
-The [Security Scanner Integration](../../../development/integrations/secure.md) documentation explains how to integrate custom security scanners into GitLab.
-
-## Analyzers Data
-
-| Property / Tool                | Apex | Bandit | Brakeman | ESLint security | SpotBugs | Flawfinder | Gosec | Kubesec Scanner | MobSF | NodeJsScan | PHP CS Security Audit | Security code Scan (.NET) | Semgrep | Sobelow |
+| Property / tool                | Apex | Bandit | Brakeman | ESLint security | SpotBugs | Flawfinder | Gosec | Kubesec Scanner | MobSF | NodeJsScan | PHP CS Security Audit | Security code Scan (.NET) | Semgrep | Sobelow |
 |--------------------------------|------|--------|----------|-----------------|----------|------------|-------|-----------------|-------|------------|-----------------------|---------------------------|---------|---------|
 | Affected item (for example, class or package) | ✓ | ✗ | ✓ | ✗               | ✓        | ✓          | ✗     | ✓               | ✗     | ✗          | ✗                     | ✗                         | ✗       | ✗       |
 | Confidence                     | ✗    | ✓      | ✓        | ✗               | ✓        | x          | ✓     | ✓               | ✗     | ✗          | ✗                     | ✗                         | ⚠       | ✓       |
@ -164,9 +88,96 @@ The [Security Scanner Integration](../../../development/integrations/secure.md)
 | Title                          | ✓    | ✓      | ✓        | ✓               | ✓        | ✓          | ✓     | ✓               | ✓     | ✓          | ✓                     | ✓                         | ✓       | ✓       |
 | URLs                           | ✓    | ✗      | ✓        | ✗               | ⚠        | ✗          | ⚠     | ✗               | ✗     | ✗          | ✗                     | ✗                         | ✗       | ✗       |

- ✓ => we have that data
- ⚠ => we have that data but it's partially reliable, or we need to extract it from unstructured content
- ✗ => we don't have that data or it would need to develop specific or inefficient/unreliable logic to obtain it.
+- ✓ => Data is available.
+- ⚠ => Data is available, but it's partially reliable, or it has to be extracted from unstructured content.
+- ✗ => Data is not available or it would require specific, inefficient or unreliable, logic to obtain it.

-The values provided by these tools are heterogeneous so they are sometimes
-normalized into common values (for example, `severity`, `confidence`, and so on).
+## Customize analyzers
+
+Use [CI/CD variables](index.md#available-cicd-variables)
+in your `.gitlab-ci.yml` file to customize the behavior of your analyzers.
+
+### Use a custom Docker mirror
+
+You can use a custom Docker registry, instead of the GitLab registry, to host the analyzers' images.
+
+Prerequisites:
+
+- The custom Docker registry must provide images for all the official analyzers.
+
+To have GitLab download the analyzers' images from a custom Docker registry, define the prefix with
+the `SECURE_ANALYZERS_PREFIX` CI/CD variable.
+
+For example, the following instructs SAST to pull `my-docker-registry/gl-images/sast/bandit` instead
+of `registry.gitlab.com/security-products/sast/bandit`:
+
+```yaml
+include:
+  - template: Security/SAST.gitlab-ci.yml
+
+variables:
+  SECURE_ANALYZERS_PREFIX: my-docker-registry/gl-images
+```
+
+### Disable all default analyzers
+
+You can disable all default SAST analyzers, leaving only [custom analyzers](#custom-analyzers)
+enabled.
+
+To disable all default analyzers, set the CI/CD variable `SAST_DISABLED` to `true` in your
+`.gitlab-ci.yml` file.
+
+Example:
+
+```yaml
+include:
+  - template: Security/SAST.gitlab-ci.yml
+
+variables:
+  SAST_DISABLED: true
+```
+
+### Disable specific default analyzers
+
+Analyzers are run automatically according to the
+source code languages detected. However, you can disable select analyzers.
+
+To disable select analyzers, set the CI/CD variable `SAST_EXCLUDED_ANALYZERS` to a comma-delimited
+string listing the analyzers that you want to prevent running.
+
+For example, to disable the `eslint` analyzer:
+
+```yaml
+include:
+  - template: Security/SAST.gitlab-ci.yml
+
+variables:
+  SAST_EXCLUDED_ANALYZERS: "eslint"
+```
+
+### Custom analyzers
+
+You can provide your own analyzers by defining jobs in your CI/CD configuration. For
+consistency with the default analyzers, you should add the suffix `-sast` to your custom
+SAST jobs.
+
+For more details on integrating a custom security scanner into GitLab, see [Security Scanner Integration](../../../development/integrations/secure.md).
+
+#### Example custom analyzer
+
+This example shows how to add a scanning job that's based on the Docker image
+`my-docker-registry/analyzers/csharp`. It runs the script `/analyzer run` and outputs a SAST report
+`gl-sast-report.json`.
+
+Define the following in your `.gitlab-ci.yml` file:
+
+```yaml
+csharp-sast:
+  image:
+    name: "my-docker-registry/analyzers/csharp"
+  script:
+    - /analyzer run
+  artifacts:
+    reports:
+      sast: gl-sast-report.json
+```
--- a/doc/user/clusters/agent/install/index.md
+++ b/doc/user/clusters/agent/install/index.md
@ -27,11 +27,23 @@ Before you can install the agent in your cluster, you need:

 To install the agent in your cluster:

+1. [Choose a name for the agent](#agent-naming-convention).
 1. [Register the agent with GitLab](#register-the-agent-with-gitlab).
 1. [Install the agent in your cluster](#install-the-agent-in-the-cluster).

 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch a GitLab 14.2 [walk-through of this process](https://www.youtube.com/watch?v=XuBpKtsgGkE).

+### Agent naming convention
+
+The agent name must follow the [DNS label standard from RFC 1123](https://tools.ietf.org/html/rfc1123).
+The name must:
+
+- Be unique in the project.
+- Contain at most 63 characters.
+- Contain only lowercase alphanumeric characters or `-`.
+- Start with an alphanumeric character.
+- End with an alphanumeric character.
+
 ### Register the agent with GitLab

 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5786) in GitLab 14.1, you can create a new agent record directly from the GitLab UI.
@ -52,7 +64,7 @@ To register an agent with GitLab:
 1. On the top bar, select **Menu > Projects** and find your project.
 1. From the left sidebar, select **Infrastructure > Kubernetes clusters**.
 1. Select **Connect a cluster (agent)**.
-   - If you want to create a configuration with CI/CD defaults, type a name for the agent.
+   - If you want to create a configuration with CI/CD defaults, type a name that meets [the naming convention](#agent-naming-convention).
   - If you already have an [agent configuration file](#create-an-agent-configuration-file), select it from the list.
 1. Select **Register an agent**.
 1. GitLab generates an access token for the agent. Securely store this token. You need it to install the agent in your cluster and to [update the agent](#update-the-agent-version) to another version.
@ -63,24 +75,23 @@ To register an agent with GitLab:
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7, the agent configuration file can be added to multiple directories (or subdirectories) of the repository.
 > - Group authorization was [introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) in GitLab 14.3.

-The agent is configured through a configuration file. This file is optional. Without a configuration file, you can still use the CI/CD workflow in the project where the agent is registered.
-
-You need a configuration file if:
+The agent uses a YAML file for configuration settings. You need a configuration file if:

 - You want to use [a GitOps workflow](../gitops.md#gitops-configuration-reference).
 - You want to authorize a different project to use the agent for a [GitLab CI/CD workflow](../ci_cd_workflow.md#authorize-the-agent).

-To create an agent configuration file, go to the GitLab project. In the repository, create a file called `config.yaml` at this path:
+To create an agent configuration file:

-```plaintext
-.gitlab/agents/<agent-name>/config.yaml
-```
+1. In the repository, create a directory in this location. The `<agent-name>` must meet [the naming convention](#agent-naming-convention).

- Ensure the agent name follows the [naming convention](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/identity_and_auth.md#agent-identity-and-name).
- Ensure the filename has the `.yaml` file extension (`config.yaml`). The `.yml` extension is not accepted.
- Add content to the `config.yaml` file:
-  - For a GitOps workflow, view [the configuration reference](../gitops.md#gitops-configuration-reference) for details.
-  - For a GitLab CI/CD workflow, you can leave the file blank for now.
+   ```plaintext
+   .gitlab/agents/<agent-name>
+   ```
+
+1. In the directory, create a `config.yaml` file. Ensure the filename ends in `.yaml`, not `.yml`.
+1. Add content to the `config.yaml` file:
+   - For a GitOps workflow, view [the configuration reference](../gitops.md#gitops-configuration-reference) for details.
+   - For a GitLab CI/CD workflow, view [the configuration reference](../ci_cd_workflow.md) for details.

 ### Install the agent in the cluster

--- a/doc/user/project/repository/push_rules.md
+++ b/doc/user/project/repository/push_rules.md
@ -6,55 +6,77 @@ info: "To determine the technical writer assigned to the Stage/Group associated

 # Push rules **(PREMIUM)**

-Gain additional control over what can and can't be pushed to your repository by using
-regular expressions to reject pushes based on commit contents, branch names or file details.
-
-GitLab already offers [protected branches](../protected_branches.md), but there are
-cases when you need some specific rules. Some common scenarios: preventing Git tag removal, or
-enforcing a special format for commit messages.
-
 Push rules are [pre-receive Git hooks](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) you
-can enable in a user-friendly interface. They are defined either:
+can enable in a user-friendly interface. Push rules give you more control over what
+can and can't be pushed to your repository. While GitLab offers
+[protected branches](../protected_branches.md), you may need more specific rules, such as:

- Globally if you are an administrator.
- Per project, so you can have different rules applied to different
-  projects depending on your needs.
+- Evaluating the contents of a commit.
+- Confirming commit messages match expected formats.
+- Enforcing branch name rules.
+- Evaluating the details of files.
+- Preventing Git tag removal.

-## Default push rules
+You can define push rules:

-The following options are available:
+- [Globally](#enable-global-push-rules), if you are an administrator.
+- [Per project](#override-global-push-rules-per-project), to create push rules that
+  meet each project's needs.
+
+These push rules are available by default:

 - **Reject unverified users** - GitLab rejects any commit that was not committed
-  by the same user as the user who pushed it, or where the committer's email address
-  is not [confirmed](../../../security/user_email_confirmation.md).
+  by the same user as the user who pushed it, or if the committer's email address
+  is [not confirmed](../../../security/user_email_confirmation.md).
 - **Reject unsigned commits** - Reject commit when it is not signed through GPG.
  Read [signing commits with GPG](gpg_signed_commits/index.md). This push rule
  can block some legitimate commits [created in the Web IDE](#reject-unsigned-commits-push-rule-disables-web-ide),
  and allow [unsigned commits created in the GitLab UI](#unsigned-commits-created-in-the-gitlab-ui).
- **Removal of tags with** `git push` - Forbid users to remove Git tags with `git push`.
+- **Do not allow users to remove Git tags with** `git push` - Forbid users to remove Git tags with `git push`.
  Tags can be deleted through the web UI.
 - **Check whether the commit author is a GitLab user** - Restrict commits to existing
  GitLab users (checked against their email addresses). Checks both the commit author and committer.
 - **Prevent pushing secret files** - GitLab rejects any files that are
  [likely to contain secrets](#prevent-pushing-secrets-to-the-repository).

-These push rules require you to create a regular expression for the rule to evaluate:
+These push rules are also available by default, but require you to create a
+regular expression for the rule to evaluate:

 - **Require expression in commit messages** - Only commit messages that match this
  regular expression can be pushed. To allow any commit message, leave empty.
  Uses multiline mode, which can be disabled using `(?-m)`.
+
+  For example, if every commit should reference a Jira issue
+  (like `Refactored css. Fixes JIRA-123.`) your regular expression would be
+  `JIRA\-\d+`. Pushes with commit messages not matching this string are declined.
 - **Reject expression in commit messages** - Only commit messages that do not match
  this regular expression can be pushed. To allow any commit message, leave empty.
  Uses multiline mode, which can be disabled using `(?-m)`.
 - **Restrict by branch name** - Only branch names that match this regular expression
-  can be pushed. To allow any branch name, leave empty. For more information, read
-  [Restrict branch names](#restrict-branch-names).
+  can be pushed. To allow any branch name, leave empty. The name of your
+  [default branch](branches/default.md) is always allowed, because many merges
+  target this branch. Include any other target branches in your regex.
+
+  Some examples:
+
+  - You may want all branches to start with a certain name (such as
+    `feature`, `hotfix`, `docker`, `android`) in support of GitLab CI/CD jobs that
+    rely on the branch name.
+  - `^JIRA-` Branches must start with `JIRA-`.
+  - `-JIRA$` Branches must end with `-JIRA`.
+  - `^[a-z0-9\\-]{4,15}$` Branches must be between `4` and `15` characters long,
+    accepting only lowercase letters, numbers and dashes.
+
+  NOTE:
+  In GitLab 12.10 and later, certain formats of branch names are restricted by
+  default for security purposes. 40-character hexadecimal names, similar to Git
+  commit hashes, are prohibited.
 - **Restrict by commit author's email** - Only the commit author's email address that matches this
  regular expression can be pushed. Checks both the commit author and committer.
  To allow any email address, leave empty.
 - **Prohibited file names** - Any committed file names that match this regular expression
  and do not already exist in the repository can't be pushed. To allow all file names,
-  leave empty. See [common examples](#prohibited-file-names).
+  leave empty. See [common examples](#prohibit-files-by-name).
 - **Maximum file size** - Pushes that contain added or updated files that exceed this
  file size (in MB) are rejected. To allow files of any size, set to `0`.
  Files tracked by Git LFS are exempted.
@ -62,62 +84,6 @@ These push rules require you to create a regular expression for the rule to eval
 GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions
 in push rules, and you can test them at the [regex101 regex tester](https://regex101.com/).

-## Custom push rules **(PREMIUM SELF)**
-
-It's possible to create custom push rules rather than the push rules available in
-**Admin Area > Push Rules** by using more advanced server hooks.
-
-Refer to [server hooks](../../../administration/server_hooks.md) for more information.
-
-## Use cases
-
-Every push rule could have its own use case, but let's consider some examples.
-
-### Commit messages with a specific reference
-
-Let's assume you have the following requirements for your workflow:
-
- every commit should reference a Jira issue, for example: `Refactored css. Fixes JIRA-123.`
- users should not be able to remove Git tags with `git push`
-
-Write a regular expression that requires the mention
-of a Jira issue in the commit message, like `JIRA\-\d+`.
-
-Now when a user tries to push a commit with a message `Bugfix`, their push is
-declined. Only pushing commits with messages like `Bugfix according to JIRA-123`
-is accepted.
-
-### Restrict branch names
-
-> Default restricted branch names were introduced in GitLab 12.10.
-
-By default, GitLab restricts certain formats of branch names for security purposes.
-40-character hexadecimal names, similar to Git commit hashes, are prohibited.
-If your company has a stricter policy for branch names, you may want the branches to start
-with a certain name. This approach enables different
-GitLab CI/CD jobs (such as `feature`, `hotfix`, `docker`, `android`) that rely on the
-branch name.
-
-Your developers may not remember that policy, so they might push to
-various branches, and CI pipelines might not work as expected. By restricting the
-branch names globally in Push Rules, such mistakes are prevented.
-All branch names that don't match your push rule are rejected.
-
-NOTE:
-The name of your default branch is always allowed, regardless of the branch naming
-regular expression (regex) specified. GitLab is configured this way
-because merges typically have the default branch as their target.
-If you have other target branches, include them in your regex. (See [Enabling push rules](#enable-global-push-rules)).
-The default branch also defaults to being a [protected branch](../protected_branches.md),
-which already limits users from pushing directly.
-
-Some example regular expressions you can use in push rules:
-
- `^JIRA-` Branches must start with `JIRA-`.
- `-JIRA$` Branches must end with `-JIRA`.
- `^[a-z0-9\\-]{4,15}$` Branches must be between `4` and `15` characters long,
-  accepting only lowercase letters, numbers and dashes.
-
 ## Enable global push rules

 You can create push rules for all new projects to inherit, but they can be overridden
@ -142,16 +108,20 @@ To override global push rules for a specific project:
 1. Set the rule you want.
 1. Select **Save push rules**.

+## Create custom push rules **(PREMIUM SELF)**
+
+You can create custom, more complex push rules with [server hooks](../../../administration/server_hooks.md).
+
 ## Prevent pushing secrets to the repository

 > Moved to GitLab Premium in 13.9.

-Secrets, such as credential files and SSH private keys, should never be committed to a version control
+Never commit secrets, such as credential files and SSH private keys, to a version control
 system. In GitLab, you can use a predefined list of files to block those files from a
-repository. Any merge request containing a file matching the list is blocked from being merged.
+repository. Merge requests containing a file matching the list are blocked, and can't merge.
 Files already committed to the repository are not restricted by this push rule.

-Files blocked by this rule are listed below. For a complete list of criteria, see
+Files blocked by this rule are listed below. For a complete list of criteria, refer to
 [`files_denylist.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/gitlab/checks/files_denylist.yml).

 - AWS CLI credential blobs:
@ -215,58 +185,75 @@ Files blocked by this rule are listed below. For a complete list of criteria, se
  - `*.history`
  - `*_history`

-## Prohibited file names
+## Prohibit files by name

 > Moved to GitLab Premium in 13.9.

-Each filename contained in a Git push is compared to the regular expression in this field. Filenames in Git consist of both the file's name and any directory that may precede it. A singular regular expression can contain multiple independent matches used as exclusions. File names can be broadly matched to any location in the repository, or restricted to specific locations. Filenames can also be partial matches used to exclude file types by extension.
+In Git, filenames include both the file's name, and all directories preceding the name.
+When you `git push`, each filename in the push is compared to the regular expression
+in **Prohibited file names**.

-The following examples make use of regex string boundary characters which match the beginning of a string (`^`), and the end (`$`). They also include instances where either the directory path or the filename can include `.` or `/`. Both of these special regex characters have to be escaped with a backslash `\\` to be used as normal characters in a match condition.
+The regular expression in your **Prohibited file names** push rule can contain multiple,
+independent matches to exclude. You can match file names broadly to any location in
+your repository, or restrict only in certain locations. Filename matches can also
+be partial, and exclude file types by extension.

-Example: prevent pushing any `.exe` files to any location in the repository. This uses a partial match, which matches any filename that contains `.exe` at the end:
+These examples use regex (regular expressions) string boundary characters to match
+the beginning of a string (`^`), and its end (`$`). They also include instances
+where either the directory path or the filename can include `.` or `/`. Both of
+these special regex characters must be escaped with a backslash `\\` if you want
+to use them as normal characters in a match condition.

-```plaintext
-\.exe$
-```
+- **Prevent pushing `.exe` files to any location in the repository** - This regex
+  matches any filename that contains `.exe` at the end:

-Example: prevent a specific configuration file in the repository root from being pushed:
+  ```plaintext
+  \.exe$
+  ```

-```plaintext
-^config\.yml$
-```
+- **Prevent pushing a specific configuration file in the repository root**

-Example: prevent a specific configuration file in a known directory from being pushed:
+  ```plaintext
+  ^config\.yml$
+  ```

-```plaintext
-^directory-name\/config\.yml$
-```
+- **Prevent pushing a specific configuration file in a known directory**

-Example: prevent the specific file named `install.exe` from being pushed to any
-location in the repository. The parenthesized expression `(^|\/)` matches either
-a file following a directory separator or a file in the root directory of the repository:
+  ```plaintext
+  ^directory-name\/config\.yml$
+  ```

-```plaintext
-(^|\/)install\.exe$
-```
+- **Prevent pushing a specific file to any location in the repository** - This example tests
+  for any file named `install.exe`. The parenthesized expression `(^|\/)` matches either
+  a file following a directory separator, or a file in the root directory of the repository:

-Example: combining all of the above in a single expression. The preceding expressions rely
-on the end-of-string character `$`. We can move that part of each expression to the
-end of the grouped collection of match conditions where it is appended to all matches:
+  ```plaintext
+  (^|\/)install\.exe$
+  ```

-```plaintext
-(\.exe|^config\.yml|^directory-name\/config\.yml|(^|\/)install\.exe)$
-```
+- **Combine all previous expressions into one expression** - The preceding expressions rely
+  on the end-of-string character `$`. We can move that part of each expression to the
+  end of the grouped collection of match conditions, where it is appended to all matches:
+
+  ```plaintext
+  (\.exe|^config\.yml|^directory-name\/config\.yml|(^|\/)install\.exe)$
+  ```
+
+## Related topics
+
+- [Server hooks](../../../administration/server_hooks.md), to create complex custom push rules
+- [Signing commits with GPG](gpg_signed_commits/index.md)
+- [Protected branches](../protected_branches.md)

 ## Troubleshooting

 ### Reject unsigned commits push rule disables Web IDE

-In 13.10, if a project has the **Reject unsigned commits** push rule, the user is not allowed to
-commit through GitLab Web IDE.
+In GitLab 13.10, if a project has the **Reject unsigned commits** push rule, the user cannot
+create commits through the GitLab Web IDE.

 To allow committing through the Web IDE on a project with this push rule, a GitLab administrator
-must disable the feature flag `reject_unsigned_commits_by_gitlab`. This can be done through a
-[rails console](../../../administration/operations/rails_console.md) and running:
+must disable the feature flag `reject_unsigned_commits_by_gitlab`. [with a flag](../../../administration/feature_flags.md)

 ```ruby
 Feature.disable(:reject_unsigned_commits_by_gitlab)
@ -274,9 +261,9 @@ Feature.disable(:reject_unsigned_commits_by_gitlab)

 ### Unsigned commits created in the GitLab UI

-This push rule ignores commits that are authenticated and created by GitLab
-(either through the UI or API). When the **Reject unsigned commits** push rule is
-enabled, unsigned commits may still show up in the commit history if a commit was
-created **in** GitLab itself. As expected, commits created outside GitLab and
+The **Reject unsigned commits** push rule ignores commits that are authenticated
+and created by GitLab (either through the UI or API). When this push rule is
+enabled, unsigned commits may still appear in the commit history if a commit was
+created in GitLab itself. As expected, commits created outside GitLab and
 pushed to the repository are rejected. For more information about this issue,
 read [issue #19185](https://gitlab.com/gitlab-org/gitlab/-/issues/19185).
--- a/lib/api/bulk_imports.rb
+++ b/lib/api/bulk_imports.rb
@ -5,6 +5,7 @@ module API
    include PaginationParams

    feature_category :importers
+    urgency :low

    helpers do
      def bulk_imports
--- a/lib/api/group_export.rb
+++ b/lib/api/group_export.rb
@ -7,6 +7,7 @@ module API
    end

    feature_category :importers
+    urgency :low

    params do
      requires :id, type: String, desc: 'The ID of a group'
--- a/lib/api/group_import.rb
+++ b/lib/api/group_import.rb
@ -3,6 +3,7 @@
 module API
  class GroupImport < ::API::Base
    feature_category :importers
+    urgency :low

    helpers Helpers::FileUploadHelpers

--- a/lib/api/import_bitbucket_server.rb
+++ b/lib/api/import_bitbucket_server.rb
@ -3,6 +3,7 @@
 module API
  class ImportBitbucketServer < ::API::Base
    feature_category :importers
+    urgency :low

    helpers do
      def client
--- a/lib/api/import_github.rb
+++ b/lib/api/import_github.rb
@ -3,6 +3,7 @@
 module API
  class ImportGithub < ::API::Base
    feature_category :importers
+    urgency :low

    rescue_from Octokit::Unauthorized, with: :provider_unauthorized

--- a/lib/api/project_export.rb
+++ b/lib/api/project_export.rb
@ -3,6 +3,7 @@
 module API
  class ProjectExport < ::API::Base
    feature_category :importers
+    urgency :low

    before do
      not_found! unless Gitlab::CurrentSettings.project_export_enabled?
--- a/lib/api/project_import.rb
+++ b/lib/api/project_import.rb
@ -8,6 +8,7 @@ module API
    helpers Helpers::FileUploadHelpers

    feature_category :importers
+    urgency :low

    before { authenticate! unless route.settings[:skip_authentication] }

--- a/lib/gitlab/diff/rendered/notebook/diff_file.rb
+++ b/lib/gitlab/diff/rendered/notebook/diff_file.rb
@ -13,6 +13,7 @@ module Gitlab
          LOG_IPYNBDIFF_GENERATED = 'IPYNB_DIFF_GENERATED'
          LOG_IPYNBDIFF_TIMEOUT = 'IPYNB_DIFF_TIMEOUT'
          LOG_IPYNBDIFF_INVALID = 'IPYNB_DIFF_INVALID'
+          LOG_IPYNBDIFF_TRUNCATED = 'IPYNB_DIFF_TRUNCATED'

          attr_reader :source_diff

@ -60,6 +61,11 @@ module Gitlab

          def notebook_diff
            strong_memoize(:notebook_diff) do
+              if source_diff.old_blob&.truncated? || source_diff.new_blob&.truncated?
+                log_event(LOG_IPYNBDIFF_TRUNCATED)
+                next
+              end
+
              Timeout.timeout(timeout_time) do
                IpynbDiff.diff(source_diff.old_blob&.data, source_diff.new_blob&.data,
                               raise_if_invalid_nb: true, diffy_opts: { include_diff_info: true })&.tap do
--- a/lib/gitlab/user_access.rb
+++ b/lib/gitlab/user_access.rb
@ -103,9 +103,7 @@ module Gitlab
    def branch_allows_collaboration_for?(ref)
      return false if skip_collaboration_check

-      # Checking for an internal project or group to prevent an infinite loop:
-      # https://gitlab.com/gitlab-org/gitlab/issues/36805
-      (!project.internal? && project.branch_allows_collaboration?(user, ref))
+      project.branch_allows_collaboration?(user, ref)
    end

    def permission_cache
--- a/spec/controllers/projects/pipelines_controller_spec.rb
+++ b/spec/controllers/projects/pipelines_controller_spec.rb
@ -19,6 +19,27 @@ RSpec.describe Projects::PipelinesController do
    sign_in(user)
  end

+  shared_examples 'the show page' do |param|
+    it 'redirects to pipeline path with param' do
+      get param, params: { namespace_id: project.namespace, project_id: project, id: pipeline }
+
+      expect(response).to redirect_to(pipeline_path(pipeline, tab: param))
+    end
+
+    context 'when the FF pipeline_tabs_vue is disabled' do
+      before do
+        stub_feature_flags(pipeline_tabs_vue: false)
+      end
+
+      it 'renders the show template' do
+        get param, params: { namespace_id: project.namespace, project_id: project, id: pipeline }
+
+        expect(response).to have_gitlab_http_status(:ok)
+        expect(response).to render_template :show
+      end
+    end
+  end
+
  describe 'GET index.json' do
    before do
      create_all_pipeline_types
@ -625,6 +646,12 @@ RSpec.describe Projects::PipelinesController do
    end
  end

+  describe 'GET dag' do
+    let(:pipeline) { create(:ci_pipeline, project: project) }
+
+    it_behaves_like 'the show page', 'dag'
+  end
+
  describe 'GET dag.json' do
    let(:pipeline) { create(:ci_pipeline, project: project) }

@ -658,6 +685,49 @@ RSpec.describe Projects::PipelinesController do
    end
  end

+  describe 'GET builds' do
+    let(:pipeline) { create(:ci_pipeline, project: project) }
+
+    it_behaves_like 'the show page', 'builds'
+  end
+
+  describe 'GET failures' do
+    let(:pipeline) { create(:ci_pipeline, project: project) }
+
+    context 'with ff `pipeline_tabs_vue` disabled' do
+      before do
+        stub_feature_flags(pipeline_tabs_vue: false)
+      end
+
+      context 'with failed jobs' do
+        before do
+          create(:ci_build, :failed, pipeline: pipeline, name: 'hello')
+        end
+
+        it 'shows the page' do
+          get :failures, params: { namespace_id: project.namespace, project_id: project, id: pipeline }
+
+          expect(response).to have_gitlab_http_status(:ok)
+          expect(response).to render_template :show
+        end
+      end
+
+      context 'without failed jobs' do
+        it 'redirects to the main pipeline page' do
+          get :failures, params: { namespace_id: project.namespace, project_id: project, id: pipeline }
+
+          expect(response).to redirect_to(pipeline_path(pipeline))
+        end
+      end
+    end
+
+    it 'redirects to the pipeline page with `failures` query param' do
+      get :failures, params: { namespace_id: project.namespace, project_id: project, id: pipeline }
+
+      expect(response).to redirect_to(pipeline_path(pipeline, tab: 'failures'))
+    end
+  end
+
  describe 'GET stages.json' do
    let(:pipeline) { create(:ci_pipeline, project: project) }

@ -988,6 +1058,12 @@ RSpec.describe Projects::PipelinesController do
    end
  end

+  describe 'GET test_report' do
+    let(:pipeline) { create(:ci_pipeline, project: project) }
+
+    it_behaves_like 'the show page', 'test_report'
+  end
+
  describe 'GET test_report.json' do
    let(:pipeline) { create(:ci_pipeline, project: project) }

--- a/spec/frontend/pipelines/components/pipeline_tabs_spec.js
+++ b/spec/frontend/pipelines/components/pipeline_tabs_spec.js
@ -21,10 +21,17 @@ describe('The Pipeline Tabs', () => {
  const findPipelineApp = () => wrapper.findComponent(PipelineGraphWrapper);
  const findTestsApp = () => wrapper.findComponent(TestReports);

+  const defaultProvide = {
+    defaultTabValue: '',
+  };
+
  const createComponent = (propsData = {}) => {
    wrapper = extendedWrapper(
      shallowMount(PipelineTabs, {
        propsData,
+        provide: {
+          ...defaultProvide,
+        },
        stubs: {
          Dag: { template: '<div id="dag"/>' },
          JobsApp: { template: '<div class="jobs" />' },
--- a/Show More
+++ b/Show More