Add latest changes from gitlab-org/gitlab@master

2021-02-19 00:11:06 +00:00 · 2021-02-19 00:11:06 +00:00 · 6f5b1492ab
parent 7131f9028d
commit 6f5b1492ab
73 changed files with 430 additions and 230 deletions
--- a/2
+++ b/2
@ -1 +1 @@
-4e5fe176e6b36866ba305e5af1ca494b031cadc8
+ec5dd7b3c441c744e4b74a083deec1f41435cb71
--- a/app/assets/javascripts/boards/components/config_toggle.vue
+++ b/app/assets/javascripts/boards/components/config_toggle.vue
@ -0,0 +1,64 @@
+<script>
+import { GlButton, GlModalDirective, GlTooltipDirective } from '@gitlab/ui';
+import { formType } from '~/boards/constants';
+import eventHub from '~/boards/eventhub';
+import { s__, __ } from '~/locale';
+
+export default {
+  components: {
+    GlButton,
+  },
+  directives: {
+    GlTooltip: GlTooltipDirective,
+    GlModalDirective,
+  },
+  props: {
+    boardsStore: {
+      type: Object,
+      required: true,
+    },
+    canAdminList: {
+      type: Boolean,
+      required: true,
+    },
+    hasScope: {
+      type: Boolean,
+      required: true,
+    },
+  },
+  data() {
+    return {
+      state: this.boardsStore.state,
+    };
+  },
+  computed: {
+    buttonText() {
+      return this.canAdminList ? s__('Boards|Edit board') : s__('Boards|View scope');
+    },
+    tooltipTitle() {
+      return this.hasScope ? __("This board's scope is reduced") : '';
+    },
+  },
+  methods: {
+    showPage() {
+      eventHub.$emit('showBoardModal', formType.edit);
+      return this.boardsStore.showPage(formType.edit);
+    },
+  },
+};
+</script>
+
+<template>
+  <div class="gl-ml-3 gl-display-flex gl-align-items-center">
+    <gl-button
+      v-gl-modal-directive="'board-config-modal'"
+      v-gl-tooltip
+      :title="tooltipTitle"
+      :class="{ 'dot-highlight': hasScope }"
+      data-qa-selector="boards_config_button"
+      @click.prevent="showPage"
+    >
+      {{ buttonText }}
+    </gl-button>
+  </div>
+</template>
--- a/app/assets/javascripts/boards/config_toggle.js
+++ b/app/assets/javascripts/boards/config_toggle.js
@ -1 +1,24 @@
-export default () => {};
+import Vue from 'vue';
+import { parseBoolean } from '~/lib/utils/common_utils';
+import ConfigToggle from './components/config_toggle.vue';
+
+export default (boardsStore) => {
+  const el = document.querySelector('.js-board-config');
+
+  if (!el) {
+    return;
+  }
+
+  gl.boardConfigToggle = new Vue({
+    el,
+    render(h) {
+      return h(ConfigToggle, {
+        props: {
+          boardsStore,
+          canAdminList: parseBoolean(el.dataset.canAdminList),
+          hasScope: parseBoolean(el.dataset.hasScope),
+        },
+      });
+    },
+  });
+};
--- a/app/assets/javascripts/boards/index.js
+++ b/app/assets/javascripts/boards/index.js
@ -6,7 +6,6 @@ import 'ee_else_ce/boards/models/issue';
 import 'ee_else_ce/boards/models/list';
 import BoardSidebar from 'ee_else_ce/boards/components/board_sidebar';
 import initNewListDropdown from 'ee_else_ce/boards/components/new_list_dropdown';
-import boardConfigToggle from 'ee_else_ce/boards/config_toggle';
 import {
  setWeightFetchingState,
  setEpicFetchingState,
@ -40,6 +39,7 @@ import {
 } from '~/lib/utils/common_utils';
 import { __ } from '~/locale';
 import sidebarEventHub from '~/sidebar/event_hub';
+import boardConfigToggle from './config_toggle';
 import mountMultipleBoardsSwitcher from './mount_multiple_boards_switcher';

 Vue.use(VueApollo);
--- a/app/assets/javascripts/pages/projects/tags/new/index.js
+++ b/app/assets/javascripts/pages/projects/tags/new/index.js
@ -3,8 +3,6 @@ import GLForm from '../../../../gl_form';
 import RefSelectDropdown from '../../../../ref_select_dropdown';
 import ZenMode from '../../../../zen_mode';

-document.addEventListener('DOMContentLoaded', () => {
-  new ZenMode(); // eslint-disable-line no-new
-  new GLForm($('.tag-form')); // eslint-disable-line no-new
-  new RefSelectDropdown($('.js-branch-select')); // eslint-disable-line no-new
-});
+new ZenMode(); // eslint-disable-line no-new
+new GLForm($('.tag-form')); // eslint-disable-line no-new
+new RefSelectDropdown($('.js-branch-select')); // eslint-disable-line no-new
--- a/app/graphql/types/mutation_type.rb
+++ b/app/graphql/types/mutation_type.rb
@ -24,6 +24,7 @@ module Types
    mount_mutation Mutations::AwardEmojis::Toggle
    mount_mutation Mutations::Boards::Create
    mount_mutation Mutations::Boards::Destroy
+    mount_mutation Mutations::Boards::Update
    mount_mutation Mutations::Boards::Issues::IssueMoveList
    mount_mutation Mutations::Boards::Lists::Create
    mount_mutation Mutations::Boards::Lists::Update
--- a/app/models/list.rb
+++ b/app/models/list.rb
@ -14,6 +14,7 @@ class List < ApplicationRecord
  validates :label_id, uniqueness: { scope: :board_id }, if: :label?

  scope :preload_associated_models, -> { preload(:board, label: :priorities) }
+  scope :without_types, ->(list_types) { where.not(list_type: list_types) }

  alias_method :preferences, :list_user_preferences

--- a/app/serializers/current_board_entity.rb
+++ b/app/serializers/current_board_entity.rb
@ -3,6 +3,8 @@
 class CurrentBoardEntity < Grape::Entity
  expose :id
  expose :name
+  expose :hide_backlog_list
+  expose :hide_closed_list
 end

 CurrentBoardEntity.prepend_if_ee('EE::CurrentBoardEntity')
--- a/app/services/boards/lists/list_service.rb
+++ b/app/services/boards/lists/list_service.rb
@ -9,7 +9,26 @@ module Boards
        end

        lists = board.lists.preload_associated_models
-        params[:list_id].present? ? lists.where(id: params[:list_id]) : lists # rubocop: disable CodeReuse/ActiveRecord
+
+        return lists.id_in(params[:list_id]) if params[:list_id].present?
+
+        list_types = unavailable_list_types_for(board)
+        lists.without_types(list_types)
+      end
+
+      private
+
+      def unavailable_list_types_for(board)
+        hidden_lists_for(board)
+      end
+
+      def hidden_lists_for(board)
+        hidden = []
+
+        hidden << ::List.list_types[:backlog] if board.hide_backlog_list
+        hidden << ::List.list_types[:closed] if board.hide_closed_list
+
+        hidden
      end
    end
  end
--- a/app/views/admin/groups/_group.html.haml
+++ b/app/views/admin/groups/_group.html.haml
@ -33,5 +33,5 @@
      = visibility_level_icon(group.visibility_level)

  .controls.gl-flex-shrink-0.gl-ml-5
-    = link_to _('Edit'), admin_group_edit_path(group), id: "edit_#{dom_id(group)}", class: 'gl-button btn'
+    = link_to _('Edit'), admin_group_edit_path(group), id: "edit_#{dom_id(group)}", class: 'btn gl-button btn-default'
    = link_to _('Delete'), [:admin, group], data: { confirm: _("Are you sure you want to remove %{group_name}?") % { group_name: group.name } }, method: :delete, class: 'gl-button btn btn-danger'
--- a/app/views/admin/projects/_projects.html.haml
+++ b/app/views/admin/projects/_projects.html.haml
@ -4,7 +4,7 @@
      - @projects.each_with_index do |project|
        %li.project-row{ class: ('no-description' if project.description.blank?) }
          .controls
-            = link_to 'Edit', edit_project_path(project), id: "edit_#{dom_id(project)}", class: "gl-button btn"
+            = link_to 'Edit', edit_project_path(project), id: "edit_#{dom_id(project)}", class: "btn gl-button btn-default"
            %button.delete-project-button.gl-button.btn.btn-danger{ data: { delete_project_url: admin_project_path(project), project_name: project.name } }
              = s_('AdminProjects|Delete')

--- a/app/views/shared/issuable/_search_bar.html.haml
+++ b/app/views/shared/issuable/_search_bar.html.haml
@ -195,7 +195,7 @@
        #js-board-labels-toggle
        - if current_user
          #js-board-epics-swimlanes-toggle
-        .js-board-config{ data: { can_admin_list: user_can_admin_list, has_scope: board.scoped? } }
+        .js-board-config{ data: { can_admin_list: user_can_admin_list.to_s, has_scope: board.scoped?.to_s } }
        - if user_can_admin_list
          - if Feature.enabled?(:board_new_list, board.resource_parent, default_enabled: :yaml)
            .js-create-column-trigger{ data: board_list_data }
--- a/changelogs/unreleased/btn-default-admin-edit.yml
+++ b/changelogs/unreleased/btn-default-admin-edit.yml
@ -0,0 +1,5 @@
+---
+title: Add btn-default class for edit buttons in admin projects and groups
+merge_request: 53453
+author:
+type: other
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@ -41,6 +41,7 @@ autoscales
 autoscaling
 awardable
 awardables
+Ayoa
 Axios
 Azure
 B-tree
@ -111,6 +112,8 @@ Contentful
 Corosync
 Coursier
 cron
+cronjob
+cronjobs
 crons
 crontab
 crontabs
@ -280,6 +283,7 @@ kaniko
 Karma
 Kerberos
 keyset
+keyspace
 keytab
 keytabs
 Kibana
@ -350,6 +354,7 @@ mixins
 mockup
 mockups
 ModSecurity
+Monokai
 monorepo
 monorepos
 multiline
@ -408,6 +413,7 @@ pooler
 postgres.ai
 PostgreSQL
 precompile
+precompiled
 preconfigure
 preconfigured
 preconfigures
@ -445,6 +451,7 @@ queryable
 Quicktime
 Rackspace
 Raspbian
+rbtrace
 Rdoc
 reachability
 Realplayer
@ -479,6 +486,7 @@ reinitialize
 reinitializing
 relicensing
 remediations
+replicables
 repmgr
 repmgrd
 repurposing
@ -521,6 +529,7 @@ Salesforce
 sandboxing
 sanitization
 sbt
+scalers
 scatterplot
 scatterplots
 Schemastore
@ -546,6 +555,7 @@ Slackbot
 Slony
 smartcard
 smartcards
+snapshotting
 Sobelow
 Solarized
 Sourcegraph
@ -564,6 +574,7 @@ strace
 strikethrough
 strikethroughs
 stunnel
+stylelint
 subfolder
 subfolders
 subgraph
@ -629,6 +640,7 @@ toolkit
 toolkits
 tooltip
 tooltips
+transactionally
 transpile
 transpiled
 transpiles
@ -637,6 +649,7 @@ Trello
 triaged
 triages
 triaging
+Trivy
 truthy
 Truststore
 Twilio
--- a/doc/README.md
+++ b/doc/README.md
@ -67,7 +67,7 @@ We have the following documentation to rapidly uplift your GitLab knowledge:
 | Topic                                                                                             | Description |
 |:--------------------------------------------------------------------------------------------------|:------------|
 | [GitLab basics guides](gitlab-basics/index.md)                                                   | Start working on the command line and with GitLab. |
-| [GitLab workflow overview](https://about.gitlab.com/blog/2016/10/25/gitlab-workflow-an-overview/) | Enhance your workflow with the best of GitLab Workflow. |
+| [GitLab workflow overview](https://about.gitlab.com/topics/version-control/what-is-gitlab-workflow/) | Enhance your workflow with the best of GitLab Workflow. |
 | [Get started with GitLab CI/CD](ci/quick_start/index.md)                                         | Quickly implement GitLab CI/CD. |
 | [Auto DevOps](topics/autodevops/index.md)                                                         | Learn more about Auto DevOps in GitLab. |
 | [GitLab Markdown](user/markdown.md)                                                               | Advanced formatting system (GitLab Flavored Markdown). |
--- a/doc/administration/consul.md
+++ b/doc/administration/consul.md
@ -146,7 +146,7 @@ sudo gitlab-ctl restart consul
 ### Consul nodes unable to communicate

 By default, Consul will attempt to
-[bind](https://www.consul.io/docs/agent/options.html#_bind) to `0.0.0.0`, but
+[bind](https://www.consul.io/docs/agent/options#_bind) to `0.0.0.0`, but
 it will advertise the first private IP address on the node for other Consul nodes
 to communicate with it. If the other nodes cannot communicate with a node on
 this address, then the cluster will have a failed status.
--- a/doc/administration/raketasks/github_import.md
+++ b/doc/administration/raketasks/github_import.md
@ -19,8 +19,8 @@ before/after the brackets. Also, some shells (for example, `zsh`) can interpret

 ## Caveats

-If the GitHub [rate limit](https://docs.github.com/v3/#rate-limiting) is reached while importing,
-the importing process waits (`sleep()`) until it can continue importing.
+If the GitHub [rate limit](https://docs.github.com/en/rest/reference/rate-limit) is reached while
+importing, the importing process waits (`sleep()`) until it can continue importing.

 ## Importing multiple projects

--- a/doc/ci/ci_cd_for_external_repos/github_integration.md
+++ b/doc/ci/ci_cd_for_external_repos/github_integration.md
@ -22,7 +22,7 @@ cannot be used to authenticate with GitHub as an external CI/CD repository.
 ## Connect with Personal Access Token

 Personal access tokens can only be used to connect GitHub.com
-repositories to GitLab, and the GitHub user must have the [owner role](https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/access-permissions-on-github).
+repositories to GitLab, and the GitHub user must have the [owner role](https://docs.github.com/en/github/getting-started-with-github/access-permissions-on-github).

 To perform a one-off authorization with GitHub to grant GitLab access your
 repositories:
--- a/doc/ci/cloud_deployment/index.md
+++ b/doc/ci/cloud_deployment/index.md
@ -319,4 +319,4 @@ For a video walkthrough of this configuration process, see [Auto Deploy to EC2](

 ## Deploy to Google Cloud

- [Deploying with GitLab on Google Cloud](https://about.gitlab.com/solutions/google-cloud-platform/)
+- [Deploying with GitLab on Google Cloud](https://about.gitlab.com/partners/technology-partners/google-cloud-platform/)
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@ -872,4 +872,4 @@ If:
 - This is the first time setting it up, carefully read
  [using Docker in Docker workflow](#use-the-docker-executor-with-the-docker-image-docker-in-docker).
 - You are upgrading from v18.09 or earlier, read our
-  [upgrade guide](https://about.gitlab.com/releases/2019/07/31/docker-in-docker-with-docker-19-dot-03/).
+  [upgrade guide](https://about.gitlab.com/blog/2019/07/31/docker-in-docker-with-docker-19-dot-03/).
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@ -1069,7 +1069,7 @@ Re-using variables defined inside `script` as part of the environment name doesn
 Below are some links you may find interesting:

 - [The `.gitlab-ci.yml` definition of environments](../yaml/README.md#environment)
- [A blog post on Deployments & Environments](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/)
+- [A blog post on Deployments & Environments](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/)
 - [Review Apps - Use dynamic environments to deploy your code for every branch](../review_apps/index.md)
 - [Deploy Boards for your applications running on Kubernetes](../../user/project/deploy_boards.md)

--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@ -70,7 +70,7 @@ Alternatively, you can use the API to protect an environment:
     name: ${CI_JOB_NAME}
   ```

-1. Use the UI to [create a new group](../../user/group/index.md#create-a-new-group).
+1. Use the UI to [create a new group](../../user/group/index.md#create-a-group).
   For example, this group is called `protected-access-group` and has the group ID `9899826`. Note
   that the rest of the examples in these steps use this group.

--- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
+++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
@ -7,8 +7,6 @@ type: tutorial

 # Authenticating and Reading Secrets With HashiCorp Vault

-> HashiCorp Vault JWT token support [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/294440) in GitLab 13.9.
-
 This tutorial demonstrates how to authenticate, configure, and read secrets with HashiCorp's Vault from GitLab CI/CD.

 NOTE:
@ -56,8 +54,8 @@ The JWT's payload looks like this:
  "ref": "auto-deploy-2020-04-01",               # Git ref for this job
  "ref_type": "branch",                          # Git ref type, branch or tag
  "ref_protected": "true",                       # true if this git ref is protected, false otherwise
-  "environment": "production",                   # Environment this job deploys to, if present
-  "environment_protected": "true"                # true if deployed environment is protected, false otherwise
+  "environment": "production",                   # Environment this job deploys to, if present (GitLab 13.9 and later)
+  "environment_protected": "true"                # true if deployed environment is protected, false otherwise (GitLab 13.9 and later)
 }
 ```

--- a/doc/ci/examples/end_to_end_testing_webdriverio/index.md
+++ b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
@ -10,6 +10,7 @@ description: 'Confidence checking your entire app every time a new feature is ad
 ---

 <!-- vale off -->
+<!-- Needs review for fixing the broken Webdriver links, which link to a deprecated version of Webdriver. -->

 # End-to-end testing with GitLab CI/CD and WebdriverIO

@ -83,7 +84,7 @@ multiple tests, such as making sure you are logged in.
 The function `it` defines an individual test.

 [The `browser` object](https://webdriver.io/guide/testrunner/browserobject.html) is WebdriverIO's
-special sauce. It provides most of [the WebdriverIO API methods](https://webdriver.io/api.html) that are the key to
+special sauce. It provides most of [the WebdriverIO API methods](https://webdriver.io/docs/api/) that are the key to
 steering the browser. In this case, we can use
 [`browser.url`](https://webdriver.io/api/protocol/url.html) to visit `/page-that-does-not-exist` to
 hit our 404 page. We can then use [`browser.getUrl`](https://webdriver.io/api/property/getUrl.html)
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@ -619,7 +619,7 @@ deploy_production:
    - master
 ```

-You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2016/08/26/ci-deployment-and-environments/), to final test your application before deploying to production.
+You may also want to add another job for [staging environment](https://about.gitlab.com/blog/2021/02/05/ci-deployment-and-environments/), to final test your application before deploying to production.

 ### Turn on GitLab CI/CD

--- a/doc/development/agent/user_stories.md
+++ b/doc/development/agent/user_stories.md
@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w

 # Kubernetes Agent user stories **(PREMIUM SELF)**

-The [personas in action](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#user-personas)
+The [personas in action](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#user-personas)
 for the Kubernetes Agent are:

 - [Sasha, the Software Developer](https://about.gitlab.com/handbook/marketing/strategic-marketing/roles-personas/#sasha-software-developer).
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@ -13,7 +13,7 @@ This document outlines the style guide for the GitLab [GraphQL API](../api/graph
 <!-- vale gitlab.Spelling = NO -->
 We use the [GraphQL Ruby gem](https://graphql-ruby.org/) written by [Robert Mosolgo](https://github.com/rmosolgo/).
 <!-- vale gitlab.Spelling = YES -->
-In addition, we have a subscription to [GraphQL Pro](https://www.graphql.pro). For details see [GraphQL Pro subscription](graphql_guide/graphql_pro.md).
+In addition, we have a subscription to [GraphQL Pro](https://graphql.pro/). For details see [GraphQL Pro subscription](graphql_guide/graphql_pro.md).

 All GraphQL queries are directed to a single endpoint
 ([`app/controllers/graphql_controller.rb#execute`](https://gitlab.com/gitlab-org/gitlab/blob/master/app%2Fcontrollers%2Fgraphql_controller.rb)),
--- a/doc/development/cicd/templates.md
+++ b/doc/development/cicd/templates.md
@ -88,7 +88,7 @@ for example `Jobs/Deploy.gitlab-ci.yml`.
 You can make a new stable template by copying [the latest template](#latest-version)
 available in a major milestone release of GitLab like `13.0`. All breaking changes
 must be announced in a blog post before the official release, for example
-[GitLab.com is moving to 13.0, with narrow breaking changes](https://about.gitlab.com/releases/2020/05/06/gitlab-com-13-0-breaking-changes/)
+[GitLab.com is moving to 13.0, with narrow breaking changes](https://about.gitlab.com/blog/2020/05/06/gitlab-com-13-0-breaking-changes/)

 You can change a stable template version in a minor GitLab release like `13.1` if:

--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@ -181,7 +181,7 @@ For instance, the "DevOps Report" category is represented by the
 `devops_reports.name` value is "DevOps Reports".

 If a category's label doesn't respect this naming convention, it should be specified
-with [the `label` attribute](https://about.gitlab.com/handbook/marketing/website/#category-attributes)
+with [the `label` attribute](https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/website/#category-attributes)
 in <https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml>.

 ### Feature labels
--- a/doc/development/distributed_tracing.md
+++ b/doc/development/distributed_tracing.md
@ -206,7 +206,7 @@ If `GITLAB_TRACING` is not configured correctly, this issue is logged:

 By default, GitLab ships with the Jaeger tracer, but other tracers can be included at compile time.
 Details of how this can be done are included in the [LabKit tracing
-documentation](https://godoc.org/gitlab.com/gitlab-org/labkit/tracing).
+documentation](https://pkg.go.dev/gitlab.com/gitlab-org/labkit/tracing).

 If no log messages about tracing are emitted, the `GITLAB_TRACING` environment variable is likely
 not set.
--- a/doc/development/documentation/testing.md
+++ b/doc/development/documentation/testing.md
@ -272,7 +272,11 @@ To configure Vale in your editor, install one of the following as appropriate:
  In the extension's settings:

  - Select the **Use CLI** checkbox.
-  - In the **Config** setting, enter an absolute path to [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini) in one of the cloned GitLab repositories on your computer.
+  - In the <!-- vale gitlab.Spelling = NO --> **Config** setting, enter an absolute
+    path to [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini)
+    in one of the cloned GitLab repositories on your computer.
+    <!-- vale gitlab.Spelling = YES -->
+
  - In the **Path** setting, enter the absolute path to the Vale binary. In most
    cases, `vale` should work. To find the location, run `which vale` in a terminal.

--- a/doc/development/go_guide/index.md
+++ b/doc/development/go_guide/index.md
@ -202,9 +202,9 @@ code readability and test output.
 ### Better output in tests

 When comparing expected and actual values in tests, use
-[`testify/require.Equal`](https://godoc.org/github.com/stretchr/testify/require#Equal),
-[`testify/require.EqualError`](https://godoc.org/github.com/stretchr/testify/require#EqualError),
-[`testify/require.EqualValues`](https://godoc.org/github.com/stretchr/testify/require#EqualValues),
+[`testify/require.Equal`](https://pkg.go.dev/github.com/stretchr/testify/require#Equal),
+[`testify/require.EqualError`](https://pkg.go.dev/github.com/stretchr/testify/require#EqualError),
+[`testify/require.EqualValues`](https://pkg.go.dev/github.com/stretchr/testify/require#EqualValues),
 and others to improve readability when comparing structs, errors,
 large portions of text, or JSON documents:

@ -363,12 +363,12 @@ There are a few guidelines one should follow when using the
 [Logrus](https://github.com/sirupsen/logrus) package:

 - When printing an error use
-  [WithError](https://godoc.org/github.com/sirupsen/logrus#WithError). For
+  [WithError](https://pkg.go.dev/github.com/sirupsen/logrus#WithError). For
  example, `logrus.WithError(err).Error("Failed to do something")`.
 - Since we use [structured logging](#structured-json-logging) we can log
  fields in the context of that code path, such as the URI of the request using
-  [`WithField`](https://godoc.org/github.com/sirupsen/logrus#WithField) or
-  [`WithFields`](https://godoc.org/github.com/sirupsen/logrus#WithFields). For
+  [`WithField`](https://pkg.go.dev/github.com/sirupsen/logrus#WithField) or
+  [`WithFields`](https://pkg.go.dev/github.com/sirupsen/logrus#WithFields). For
  example, `logrus.WithField("file", "/app/go").Info("Opening dir")`. If you
  have to log multiple keys, always use `WithFields` instead of calling
  `WithField` more than once.
@ -488,7 +488,7 @@ The following are some style guidelines that are specific to the Secure Team.
 ### Code style and format

 Use `goimports -local gitlab.com/gitlab-org` before committing.
-[`goimports`](https://godoc.org/golang.org/x/tools/cmd/goimports)
+[`goimports`](https://pkg.go.dev/golang.org/x/tools/cmd/goimports)
 is a tool that automatically formats Go source code using
 [`Gofmt`](https://golang.org/cmd/gofmt/), in addition to formatting import lines,
 adding missing ones and removing unreferenced ones.
--- a/doc/development/image_scaling.md
+++ b/doc/development/image_scaling.md
@ -73,7 +73,7 @@ we simply follow the path we take to serve any ordinary upload.
 ### Workhorse

 Assuming Rails decided the request to be valid, Workhorse will take over. Upon receiving the `send-scaled-image`
-instruction through the Rails response, a [special response injecter](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/master/internal/imageresizer/image_resizer.go)
+instruction through the Rails response, a [special response injector](https://gitlab.com/gitlab-org/gitlab-workhorse/-/blob/master/internal/imageresizer/image_resizer.go)
 will be invoked that knows how to rescale images. The only inputs it requires are the location of the image
 (a path if the image resides in block storage, or a URL to remote storage otherwise) and the desired width.
 Workhorse will handle the location transparently so Rails does not need to be concerned with where the image
--- a/doc/development/integrations/secure_partner_integration.md
+++ b/doc/development/integrations/secure_partner_integration.md
@ -13,7 +13,7 @@ guidelines so you can build an integration that fits with the workflow GitLab
 users are already familiar with.

 This page also provides resources for the technical work associated
-with [onboarding as a partner](https://about.gitlab.com/partners/integrate/).
+with [onboarding as a partner](https://about.gitlab.com/partners/technology-partners/integrate/).
 The steps below are a high-level view of what needs to be done to complete an
 integration as well as linking to more detailed resources for how to do so.

--- a/doc/development/namespaces_storage_statistics.md
+++ b/doc/development/namespaces_storage_statistics.md
@ -140,7 +140,7 @@ Even though this approach would make aggregating much easier, it has some major
 - We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost would be significant. The background migration would take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29772>.
 - Background migration has to be shipped one release before, delaying the functionality by another milestone.

-### Attempt E (final): Update the namespace storage statistics in async way
+### Attempt E (final): Update the namespace storage statistics asynchronously

 This approach consists of continuing to use the incremental statistics updates we already have,
 but we refresh them through Sidekiq jobs and in different transactions:
@ -149,7 +149,7 @@ but we refresh them through Sidekiq jobs and in different transactions:
 1. Whenever the statistics of a project changes, insert a row into `namespace_aggregation_schedules`
   - We don't insert a new row if there's already one related to the root namespace.
   - Keeping in mind the length of the transaction that involves updating `project_statistics`(<https://gitlab.com/gitlab-org/gitlab/-/issues/29070>), the insertion should be done in a different transaction and through a Sidekiq Job.
-1. After inserting the row, we schedule another worker to be executed async at two different moments:
+1. After inserting the row, we schedule another worker to be executed asynchronously at two different moments:
   - One enqueued for immediate execution and another one scheduled in `1.5h` hours.
   - We only schedule the jobs, if we can obtain a `1.5h` lease on Redis on a key based on the root namespace ID.
   - If we can't obtain the lease, it indicates there's another aggregation already in progress, or scheduled in no more than `1.5h`.
@ -161,7 +161,7 @@ but we refresh them through Sidekiq jobs and in different transactions:

 This implementation has the following benefits:

- All the updates are done async, so we're not increasing the length of the transactions for `project_statistics`.
+- All the updates are done asynchronously, so we're not increasing the length of the transactions for `project_statistics`.
 - We're doing the update in a single SQL query.
 - It is compatible with PostgreSQL and MySQL.
 - No background migration required.
--- a/doc/development/new_fe_guide/development/components.md
+++ b/doc/development/new_fe_guide/development/components.md
@ -19,7 +19,7 @@ D3 is very popular across many projects outside of GitLab:

 - [The New York Times](https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html)
 - [plot.ly](https://plotly.com/)
- [Droptask](https://www.ayoa.com/previously-droptask/)
+- [Ayoa](https://www.ayoa.com/previously-droptask/)

 Within GitLab, D3 has been used for the following notable features

--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@ -256,7 +256,7 @@ The following configuration options can be configured:
 - `STACKPROF_MODE`: See [sampling modes](https://github.com/tmm1/stackprof#sampling).
  Defaults to `cpu`.
 - `STACKPROF_INTERVAL`: Sampling interval. Unit semantics depend on `STACKPROF_MODE`.
-  For `object` mode this is a per-event interval (every `n`th event is sampled)
+  For `object` mode this is a per-event interval (every `nth` event is sampled)
  and defaults to `1000`.
  For other modes such as `cpu` this is a frequency and defaults to `10000` μs (100hz).
 - `STACKPROF_FILE_PREFIX`: File path prefix where profiles are stored. Defaults
@ -293,7 +293,7 @@ worker processes), selecting the latter.

 For Sidekiq, the signal can be sent to the `sidekiq-cluster` process via `pkill
 -USR2 bin/sidekiq-cluster`, which forwards the signal to all Sidekiq
-children. Alternatively, you can also select a specific pid of interest.
+children. Alternatively, you can also select a specific PID of interest.

 Production profiles can be especially noisy. It can be helpful to visualize them
 as a [flame graph](https://github.com/brendangregg/FlameGraph). This can be done
@ -306,7 +306,7 @@ bundle exec stackprof --stackcollapse /tmp/stackprof.55769.c6c3906452.profile |
 ## RSpec profiling

 The GitLab development environment also includes the
-[rspec_profiling](https://github.com/foraker/rspec_profiling) gem, which is used
+[`rspec_profiling`](https://github.com/foraker/rspec_profiling) gem, which is used
 to collect data on spec execution times. This is useful for analyzing the
 performance of the test suite itself, or seeing how the performance of a spec
 may have changed over time.
@ -409,7 +409,7 @@ Fragmented Ruby heap snapshot could look like this:

 ![Ruby heap fragmentation](img/memory_ruby_heap_fragmentation.png)

-Memory fragmentation could be reduced by tuning GC parameters as described in [this post by Nate Berkopec](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html). This should be considered as a tradeoff, as it may affect overall performance of memory allocation and GC cycles.
+Memory fragmentation could be reduced by tuning GC parameters [as described in this post](https://www.speedshop.co/2017/12/04/malloc-doubles-ruby-memory.html). This should be considered as a tradeoff, as it may affect overall performance of memory allocation and GC cycles.

 ## Importance of Changes

--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@ -426,7 +426,7 @@ We are using a custom mapping between source file to test files, maintained in t

 ### PostgreSQL versions testing

-Even though [Omnibus defaults to PG12 for new installs and upgrades](https://docs.gitlab.com/omnibus/package-information/postgresql_versions.md),
+Even though [Omnibus defaults to PG12 for new installs and upgrades](https://docs.gitlab.com/omnibus/package-information/postgresql_versions.html),
 our test suite is currently running against PG11, since GitLab.com still runs on PG11.

 We do run our test suite against PG12 on nightly scheduled pipelines as well as upon specific
--- a/doc/development/query_performance.md
+++ b/doc/development/query_performance.md
@ -25,7 +25,7 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent

 - When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
 - When working with batched queries, change the range and batch size to see how it effects the query timing and caching.
- If an existing query is already underperforming, make an effort to improve it. If it is too complex or would stall development, create a follow-up so it can be addressed in a timely manner. You can always ask the database reviewer or maintainer for help and guidance.
+- If an existing query is not performing well, make an effort to improve it. If it is too complex or would stall development, create a follow-up so it can be addressed in a timely manner. You can always ask the database reviewer or maintainer for help and guidance.

 ## Cold and warm cache

--- a/doc/development/redis.md
+++ b/doc/development/redis.md
@ -120,14 +120,13 @@ This shows commands that have taken a long time and may be a performance
 concern.

 The
-[fluent-plugin-redis-slowlog](https://gitlab.com/gitlab-org/fluent-plugin-redis-slowlog)
-project is responsible for taking the slowlog entries from Redis and
-passing to fluentd (and ultimately Elasticsearch).
+[`fluent-plugin-redis-slowlog`](https://gitlab.com/gitlab-org/fluent-plugin-redis-slowlog)
+project is responsible for taking the `slowlog` entries from Redis and
+passing to Fluentd (and ultimately Elasticsearch).

 ## Analyzing the entire keyspace

-The [Redis Keyspace
-Analyzer](https://gitlab.com/gitlab-com/gl-infra/redis-keyspace-analyzer)
+The [Redis Keyspace Analyzer](https://gitlab.com/gitlab-com/gl-infra/redis-keyspace-analyzer)
 project contains tools for dumping the full key list and memory usage of a Redis
 instance, and then analyzing those lists while eliminating potentially sensitive
 data from the results. It can be used to find the most frequent key patterns, or
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@ -195,7 +195,7 @@ Go's [`regexp`](https://golang.org/pkg/regexp/) package uses `re2` and isn't vul
 - [Rubular](https://rubular.com/) is a nice online tool to fiddle with Ruby Regexps.
 - [Runaway Regular Expressions](https://www.regular-expressions.info/catastrophic.html)
 - [The impact of regular expression denial of service (ReDoS) in practice: an empirical study at the ecosystem scale](https://people.cs.vt.edu/~davisjam/downloads/publications/DavisCoghlanServantLee-EcosystemREDOS-ESECFSE18.pdf). This research paper discusses approaches to automatically detect ReDoS vulnerabilities.
- [Freezing the web: A study of redos vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.
+- [Freezing the web: A study of ReDoS vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.

 ## Server Side Request Forgery (SSRF)

--- a/doc/development/sidekiq_style_guide.md
+++ b/doc/development/sidekiq_style_guide.md
@ -588,7 +588,7 @@ the `.with_route` scope defined on all `Routable`s.

 ### Cron workers

-The context is automatically cleared for workers in the Cronjob queue
+The context is automatically cleared for workers in the cronjob queue
 (`include CronjobQueue`), even when scheduling them from
 requests. We do this to avoid incorrect metadata when other jobs are
 scheduled from the cron worker.
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@ -800,10 +800,11 @@ end
 ```

 WARNING:
-Only use simple values as input in the `where` block. Using procs, stateful
+Only use simple values as input in the `where` block. Using
+<!-- vale gitlab.Spelling = NO --> procs, stateful
 objects, FactoryBot-created objects, and similar items can lead to
 [unexpected results](https://github.com/tomykaira/rspec-parameterized/issues/8).
-
+<!-- vale gitlab.Spelling = YES -->
 ### Prometheus tests

 Prometheus metrics may be preserved from one test run to another. To ensure that metrics are
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@ -193,7 +193,7 @@ When it comes to querying DOM elements in your tests, it is best to uniquely and
 the element.

 Preferentially, this is done by targeting what the user actually sees using [DOM Testing Library](https://testing-library.com/docs/dom-testing-library/intro/).
-When selecting by text it is best to use [`getByRole` or `findByRole`](https://testing-library.com/docs/dom-testing-library/api-queries/#byrole)
+When selecting by text it is best to use [`getByRole` or `findByRole`](https://testing-library.com/docs/queries/byrole)
 as these enforce accessibility best practices as well. The examples below demonstrate the order of preference.

 When writing Vue component unit tests, it can be wise to query children by component, so that the unit test can focus on comprehensive value coverage
@ -687,7 +687,7 @@ Similarly, if you really need to use the real `Date` class, then you can import
 ```javascript
 import { useRealDate } from 'helpers/fake_date';

-// NOTE: `useRealDate` cannot be called during test execution (i.e. inside `it`, `beforeEach`, `beforeAll`, etc.). 
+// NOTE: `useRealDate` cannot be called during test execution (i.e. inside `it`, `beforeEach`, `beforeAll`, etc.).
 describe('with real date', () => {
  useRealDate();
 });
@ -1034,7 +1034,7 @@ describe "Admin::AbuseReports", :js do
 end
 ```

-### Jest test timeout due to async imports
+### Jest test timeout due to asynchronous imports

 If a module asynchronously imports some other modules at runtime, these modules must be
 transpiled by the Jest loaders at runtime. It's possible that this can cause [Jest to timeout](https://gitlab.com/gitlab-org/gitlab/-/issues/280809).
--- a/doc/development/usage_ping.md
+++ b/doc/development/usage_ping.md
@ -840,7 +840,9 @@ We also use `#database-lab` and [explain.depesz.com](https://explain.depesz.com/

 ### 5. Add the metric definition

-When adding, changing, or updating metrics, please update the [Event Dictionary's **Usage Ping** table](https://about.gitlab.com/handbook/product/product-intelligence-guide/#event-dictionary).
+[Check Metrics Dictionary Guide](usage_ping/metrics_dictionary.md)
+
+When adding, updating, or removing metrics, please update the [Metrics Dictionary](usage_ping/dictionary.md).

 ### 6. Add new metric to Versions Application

--- a/doc/gitlab-basics/index.md
+++ b/doc/gitlab-basics/index.md
@ -23,7 +23,7 @@ The following are guides to basic GitLab functionality:

 - [Create and add your SSH public key](../ssh/README.md), for enabling Git over SSH.
 - [Create a project](../user/project/working_with_projects.md#create-a-project), to start using GitLab.
- [Create a group](../user/group/index.md#create-a-new-group), to combine and administer
+- [Create a group](../user/group/index.md#create-a-group), to combine and administer
  projects together.
 - [Create a branch](create-branch.md), to make changes to files stored in a project's repository.
 - [Feature branch workflow](feature_branch_workflow.md).
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@ -13,15 +13,15 @@ You should also reference the [OmniAuth documentation](omniauth.md) for general

 ## Common SAML Terms

-| Term | Description |
-|------|-------------|
-| Identity Provider (IdP) | The service which manages your user identities such as ADFS, Okta, Onelogin, or Ping Identity. |
-| Service Provider (SP) | SAML considers GitLab to be a service provider. |
-| Assertion | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
-| SSO | Single Sign-On. |
+| Term                           | Description |
+|--------------------------------|-------------|
+| Identity Provider (IdP)        | The service which manages your user identities, such as ADFS, Okta, OneLogin, or Ping Identity. |
+| Service Provider (SP)          | SAML considers GitLab to be a service provider. |
+| Assertion                      | A piece of information about a user's identity, such as their name or role. Also known as claims or attributes. |
+| SSO                            | Single Sign-On. |
 | Assertion consumer service URL | The callback on GitLab where users will be redirected after successfully authenticating with the identity provider. |
-| Issuer | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
-| Certificate fingerprint | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |
+| Issuer                         | How GitLab identifies itself to the identity provider. Also known as a "Relying party trust identifier". |
+| Certificate fingerprint        | Used to confirm that communications over SAML are secure by checking that the server is signing communications with the correct certificate. Also known as a certificate thumbprint. |

 ## General Setup

@ -265,7 +265,7 @@ considered admin users.

 ### Auditor groups **(PREMIUM SELF)**

-> Introduced in [GitLab Starter](https://about.gitlab.com/pricing/) 11.4.
+> Introduced in GitLab 11.4.

 The requirements are the same as the previous settings, your IdP needs to pass Group information to GitLab, you need to tell
 GitLab where to look for the groups in the SAML response, and which group(s) should be
@ -454,8 +454,6 @@ args: {

 ### `uid_attribute`

-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17734) in GitLab 10.7.
-
 By default, the `uid` is set as the `name_id` in the SAML response. If you'd like to designate a unique attribute for the `uid`, you can set the `uid_attribute`. In the example below, the value of `uid` attribute in the SAML response is set as the `uid_attribute`.

 ```yaml
--- a/doc/intro/index.md
+++ b/doc/intro/index.md
@ -12,7 +12,7 @@ comments: false
 Create projects and groups.

 - [Create a new project](../user/project/working_with_projects.md#create-a-project)
- [Create a new group](../user/group/index.md#create-a-new-group)
+- [Create a new group](../user/group/index.md#create-a-group)

 ## Prioritize

--- a/doc/ssh/README.md
+++ b/doc/ssh/README.md
@ -77,7 +77,7 @@ If you do not have an existing SSH key pair, generate a new one.
 1. Type `ssh-keygen -t` followed by the key type and an optional comment.
   This comment is included in the `.pub` file that's created.
   You may want to use an email address for the comment.
-  
+
   For example, for ED25519:

   ```shell
@ -111,7 +111,7 @@ If you do not have an existing SSH key pair, generate a new one.

 1. A confirmation is displayed, including information about where your files are stored.

-A public and private key are generated. 
+A public and private key are generated.
 [Add the public SSH key to your GitLab account](#add-an-ssh-key-to-your-gitlab-account) and keep
 the private key secure.

@ -278,7 +278,7 @@ Instead, you can assign aliases to hosts in the `~.ssh/config` file.
 - For the `Host`, use an alias like `user_1.gitlab.com` and
  `user_2.gitlab.com`. Advanced configurations
  are more difficult to maintain, and these strings are easier to
-  understand when you use tools like `git remote`. 
+  understand when you use tools like `git remote`.
 - For the `IdentityFile`, use the path the private key.

 ```conf
--- a/doc/topics/autodevops/customize.md
+++ b/doc/topics/autodevops/customize.md
@ -17,7 +17,7 @@ staging and canary deployments,
 ## Custom buildpacks

 If the automatic buildpack detection fails for your project, or if you want to
-use a custom buildpack, you can override the buildpack using a project variable
+use a custom buildpack, you can override the buildpack using a project CI/CD variable
 or a `.buildpacks` file in your project:

 - **Project variable** - Create a project variable `BUILDPACK_URL` with the URL
@ -43,7 +43,7 @@ can't use the `.buildpacks` file. The buildpack
 in the backend to parse the `.buildpacks` file, does not provide the necessary commands
 `bin/test-compile` and `bin/test`.

-If your goal is to use only a single custom buildpack, you should provide the project variable
+If your goal is to use only a single custom buildpack, you should provide the project CI/CD variable
 `BUILDPACK_URL` instead.

 ## Custom `Dockerfile`
@ -55,13 +55,13 @@ builds a Docker image based on the Dockerfile, rather than using buildpacks.
 This can be much faster and result in smaller images, especially if your
 Dockerfile is based on [Alpine](https://hub.docker.com/_/alpine/).

-If you set the `DOCKERFILE_PATH` CI variable, Auto Build looks for a Dockerfile there
+If you set the `DOCKERFILE_PATH` CI/CD variable, Auto Build looks for a Dockerfile there
 instead.

 ## Passing arguments to `docker build`

 Arguments can be passed to the `docker build` command using the
-`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` project variable. For example, to build a
+`AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` project CI/CD variable. For example, to build a
 Docker image based on based on the `ruby:alpine` instead of the default `ruby:latest`:

 1. Set `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS` to `--build-arg=RUBY_VERSION=alpine`.
@ -93,12 +93,12 @@ You can extend and manage your Auto DevOps configuration with GitLab APIs:
 - [Editing groups](../../api/groups.md#update-group).
 - [Editing projects](../../api/projects.md#edit-project).

-## Forward CI variables to the build environment
+## Forward CI/CD variables to the build environment

 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/25514) in GitLab 12.3, but available in versions 11.9 and above.

-CI variables can be forwarded into the build environment using the
-`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI variable.
+CI/CD variables can be forwarded into the build environment using the
+`AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` CI/CD variable.
 The forwarded variables should be specified by name in a comma-separated
 list. For example, to forward the variables `CI_COMMIT_SHA` and
 `CI_ENVIRONMENT_NAME`, set `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES`
@ -130,7 +130,7 @@ feature to use the `--secret` flag.

 Auto DevOps uses [Helm](https://helm.sh/) to deploy your application to Kubernetes.
 You can override the Helm chart used by bundling up a chart into your project
-repository or by specifying a project variable:
+repository or by specifying a project CI/CD variable:

 - **Bundled chart** - If your project has a `./chart` directory with a `Chart.yaml`
  file in it, Auto DevOps detects the chart and uses it instead of the
@ -151,17 +151,17 @@ You can override the default values in the `values.yaml` file in the
 - Adding a file named `.gitlab/auto-deploy-values.yaml` to your repository, which is
  automatically used, if found.
 - Adding a file with a different name or path to the repository, and setting the
-  `HELM_UPGRADE_VALUES_FILE` [environment variable](#environment-variables) with
+  `HELM_UPGRADE_VALUES_FILE` [CI/CD variable](#cicd-variables) with
  the path and name.

 NOTE:
-For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` environment variable
+For GitLab 12.5 and earlier, use the `HELM_UPGRADE_EXTRA_ARGS` variable
 to override the default chart values by setting `HELM_UPGRADE_EXTRA_ARGS` to `--values <my-values.yaml>`.

 ## Customize the `helm upgrade` command

 You can customize the `helm upgrade` command used in the [auto-deploy-image](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image)
-by passing options to the command with the `HELM_UPGRADE_EXTRA_ARGS` variable.
+by passing options to the command with the `HELM_UPGRADE_EXTRA_ARGS` CI/CD variable.
 For example, set the value of `HELM_UPGRADE_EXTRA_ARGS` to `--no-hooks` to disable
 pre-upgrade and post-upgrade hooks when the command is executed.

@ -170,7 +170,7 @@ list of options.

 ## Custom Helm chart per environment

-You can specify the use of a custom Helm chart per environment by scoping the environment variable
+You can specify the use of a custom Helm chart per environment by scoping the CI/CD variable
 to the desired environment. See [Limiting environment scopes of variables](../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables).

 ## Customizing `.gitlab-ci.yml`
@ -260,7 +260,7 @@ the [GitLab 12.10 based templates](https://gitlab.com/gitlab-org/auto-devops-v12
 To support applications requiring a database,
 [PostgreSQL](https://www.postgresql.org/) is provisioned by default. The credentials to access
 the database are preconfigured, but can be customized by setting the associated
-[variables](#environment-variables). You can use these credentials to define a `DATABASE_URL`:
+[CI/CD variables](#cicd-variables). You can use these credentials to define a `DATABASE_URL`:

 ```yaml
 postgres://user:password@postgres-host:postgres-port/postgres-database
@ -269,7 +269,7 @@ postgres://user:password@postgres-host:postgres-port/postgres-database
 ### Upgrading PostgresSQL

 WARNING:
-The variable `AUTO_DEVOPS_POSTGRES_CHANNEL` that controls default provisioned
+The CI/CD variable `AUTO_DEVOPS_POSTGRES_CHANNEL` that controls default provisioned
 PostgreSQL was changed to `2` in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/210499).
 To keep using the old PostgreSQL, set the `AUTO_DEVOPS_POSTGRES_CHANNEL` variable to
 `1`.
@ -290,17 +290,17 @@ production environments, for some use cases, it may not be sufficiently secure o
 resilient, and you may want to use an external managed provider (such as
 AWS Relational Database Service) for PostgreSQL.

-You must define environment-scoped variables for `POSTGRES_ENABLED` and
+You must define environment-scoped CI/CD variables for `POSTGRES_ENABLED` and
 `DATABASE_URL` in your project's CI/CD settings:

 1. Disable the built-in PostgreSQL installation for the required environments using
-   scoped [environment variables](../../ci/environments/index.md#scoping-environments-with-specs).
+   environment-scoped [CI/CD variables](../../ci/environments/index.md#scoping-environments-with-specs).
   For this use case, it's likely that only `production` must be added to this
   list. The built-in PostgreSQL setup for Review Apps and staging is sufficient.

   ![Auto Metrics](img/disable_postgres.png)

-1. Define the `DATABASE_URL` CI variable as a scoped environment variable that is
+1. Define the `DATABASE_URL` variable as an environment-scoped variable that is
   available to your application. This should be a URL in the following format:

   ```yaml
@ -310,7 +310,7 @@ You must define environment-scoped variables for `POSTGRES_ENABLED` and
 You must ensure that your Kubernetes cluster has network access to wherever
 PostgreSQL is hosted.

-## Environment variables
+## CI/CD variables

 The following variables can be used for setting up the Auto DevOps domain,
 providing a custom Helm chart, or scaling your application. PostgreSQL can
@ -318,10 +318,10 @@ also be customized, and you can use a [custom buildpack](#custom-buildpacks).

 ### Build and deployment

-The following table lists variables related to building and deploying
+The following table lists CI/CD variables related to building and deploying
 applications.

-| **Variable**                            | **Description**                    |
+| **CI/CD Variable**                      | **Description**                    |
 |-----------------------------------------|------------------------------------|
 | `ADDITIONAL_HOSTS`                      | Fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. |
 | `<ENVIRONMENT>_ADDITIONAL_HOSTS`        | For a specific environment, the fully qualified domain names specified as a comma-separated list that are added to the Ingress hosts. This takes precedence over `ADDITIONAL_HOSTS`. |
@ -329,7 +329,7 @@ applications.
 | `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED`   | When set to a non-empty value and no `Dockerfile` is present, Auto Build builds your application using Cloud Native Buildpacks instead of Herokuish. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
 | `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`   | The builder used when building with Cloud Native Buildpacks. The default builder is `heroku/buildpacks:18`. [More details](stages.md#auto-build-using-cloud-native-buildpacks-beta). |
 | `AUTO_DEVOPS_BUILD_IMAGE_EXTRA_ARGS`    | Extra arguments to be passed to the `docker build` command. Note that using quotes doesn't prevent word splitting. [More details](#passing-arguments-to-docker-build). |
-| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI variable names](#forward-ci-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
+| `AUTO_DEVOPS_BUILD_IMAGE_FORWARDED_CI_VARIABLES` | A [comma-separated list of CI/CD variable names](#forward-cicd-variables-to-the-build-environment) to be forwarded to the build environment (the buildpack builder or `docker build`). |
 | `AUTO_DEVOPS_CHART`                     | Helm Chart used to deploy your apps. Defaults to the one [provided by GitLab](https://gitlab.com/gitlab-org/cluster-integration/auto-deploy-image/-/tree/master/assets/auto-deploy-app). |
 | `AUTO_DEVOPS_CHART_REPOSITORY`          | Helm Chart repository used to search for charts. Defaults to `https://charts.gitlab.io`. |
 | `AUTO_DEVOPS_CHART_REPOSITORY_NAME`     | From GitLab 11.11, used to set the name of the Helm repository. Defaults to `gitlab`. |
@ -367,9 +367,9 @@ Auto DevOps can undo your changes.

 ### Database

-The following table lists variables related to the database.
+The following table lists CI/CD variables related to the database.

-| **Variable**                            | **Description**                    |
+| **CI/CD Variable**                            | **Description**                    |
 |-----------------------------------------|------------------------------------|
 | `DB_INITIALIZE`                         | From GitLab 11.4, used to specify the command to run to initialize the application's PostgreSQL database. Runs inside the application pod. |
 | `DB_MIGRATE`                            | From GitLab 11.4, used to specify the command to run to migrate the application's PostgreSQL database. Runs inside the application pod. |
@ -383,7 +383,7 @@ The following table lists variables related to the database.

 The following table lists variables used to disable jobs.

-| **Job Name**                           | **Variable**                    | **GitLab version**    | **Description** |
+| **Job Name**                           | **CI/CDVariable**               | **GitLab version**    | **Description** |
 |----------------------------------------|---------------------------------|-----------------------|-----------------|
 | `.fuzz_base`                           | `COVFUZZ_DISABLED`              | [From GitLab 13.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34984) | [Read more](../../user/application_security/coverage_fuzzing/) about how `.fuzz_base` provide capability for your own jobs. If the variable is present, your jobs aren't created. |
 | `apifuzzer_fuzz`                       | `API_FUZZING_DISABLED`          | [From GitLab 13.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39135) | If the variable is present, the job isn't created. |
@ -433,7 +433,7 @@ The following table lists variables used to disable jobs.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/49056) in GitLab 11.7.

 Some applications need to define secret variables that are accessible by the deployed
-application. Auto DevOps detects variables starting with `K8S_SECRET_`, and makes
+application. Auto DevOps detects CI/CD variables starting with `K8S_SECRET_`, and makes
 these prefixed variables available to the deployed application as environment variables.

 To configure your application variables:
@ -545,7 +545,7 @@ The normal behavior of Auto DevOps is to use continuous deployment, pushing
 automatically to the `production` environment every time a new pipeline is run
 on the default branch. However, there are cases where you might want to use a
 staging environment, and deploy to production manually. For this scenario, the
-`STAGING_ENABLED` environment variable was introduced.
+`STAGING_ENABLED` CI/CD variable was introduced.

 If you define `STAGING_ENABLED` with a non-empty value, then GitLab automatically deploys the application
 to a `staging` environment, and creates a `production_manual` job for
@ -584,7 +584,7 @@ are created:
 1. `rollout 50%`
 1. `rollout 100%`

-The percentage is based on the `REPLICAS` variable, and defines the number of
+The percentage is based on the `REPLICAS` CI/CD variable, and defines the number of
 pods you want to have for your deployment. If the value is `10`, and you run the
 `10%` rollout job, there is `1` new pod and `9` old ones.

@ -616,8 +616,8 @@ With `INCREMENTAL_ROLLOUT_MODE` set to `manual` and with `STAGING_ENABLED`
 ![Rollout and staging enabled](img/rollout_staging_enabled.png)

 WARNING:
-Before GitLab 11.4, the presence of the `INCREMENTAL_ROLLOUT_ENABLED` environment
-variable enabled this feature. This configuration is deprecated, and is scheduled to be
+Before GitLab 11.4, the presence of the `INCREMENTAL_ROLLOUT_ENABLED` CI/CD variable
+enabled this feature. This configuration is deprecated, and is scheduled to be
 removed in the future.

 ### Timed incremental rollout to production **(PREMIUM)**
@ -632,7 +632,7 @@ This configuration is based on

 Everything behaves the same way, except:

- To enable it, set the `INCREMENTAL_ROLLOUT_MODE` variable to `timed`.
+- To enable it, set the `INCREMENTAL_ROLLOUT_MODE` CI/CD variable to `timed`.
 - Instead of the standard `production` job, the following jobs are created with
  a 5 minute delay between each:

--- a/doc/topics/autodevops/img/alexj_autodevops_min_v13_8.png
+++ b/doc/topics/autodevops/img/alexj_autodevops_min_v13_8.png
--- a/doc/topics/autodevops/img/kai_autodevops_min_v13_8.png
+++ b/doc/topics/autodevops/img/kai_autodevops_min_v13_8.png
--- a/doc/topics/autodevops/index.md
+++ b/doc/topics/autodevops/index.md
@ -31,25 +31,12 @@ management of processes, and faster creation of new projects: push your code,
 and GitLab does the rest, improving your productivity and efficiency.

 <i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
-For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4).
+For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4) or see this [overview](https://about.gitlab.com/stages-devops-lifecycle/auto-devops/).

 For requirements, read [Requirements for Auto DevOps](requirements.md) for more information.

 For a developer's guide, read [Auto DevOps development guide](../../development/auto_devops.md).

-### Share your feedback
-
-As Auto DevOps continues to gain popularity, and lowers the barrier to entry for
-getting started with DevOps and CI/CD, see what our wider community is saying:
-
-From [AlexJonesax](https://twitter.com/AlexJonesax) and [KaiPMDH](https://twitter.com/KaiPMDH) on Twitter:
-
-![Alex on Twitter: Auto DevOps in GitLab doesn't just lower the bar to entry, it removes the bar and holds your hand.](img/alexj_autodevops_min_v13_8.png)
-
-![Kai on Twitter: When I saw this on the Auto DevOps stuff, my mind was blown...](img/kai_autodevops_min_v13_8.png)
-
-We welcome everyone to [share your experience by tagging GitLab on Twitter](https://twitter.com/gitlab).
-
 ## Enabled by default

 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/41729) in GitLab 11.3.
--- a/doc/topics/autodevops/quick_start_guide.md
+++ b/doc/topics/autodevops/quick_start_guide.md
@ -234,8 +234,8 @@ takes you to the pod's logs page.

 NOTE:
 The example shows only one pod hosting the application at the moment, but you can add
-more pods by defining the [`REPLICAS` variable](customize.md#environment-variables)
-in **Settings > CI/CD > Environment variables**.
+more pods by defining the [`REPLICAS` CI/CD variable](customize.md#cicd-variables)
+in **Settings > CI / CD > Variables**.

 ### Work with branches

@ -307,7 +307,7 @@ and customized to fit your workflow. Here are some helpful resources for further
 1. [Auto DevOps](index.md)
 1. [Multiple Kubernetes clusters](index.md#using-multiple-kubernetes-clusters)
 1. [Incremental rollout to production](customize.md#incremental-rollout-to-production) **(PREMIUM)**
-1. [Disable jobs you don't need with environment variables](customize.md#environment-variables)
+1. [Disable jobs you don't need with CI/CD variables](customize.md#cicd-variables)
 1. [Use a static IP for your cluster](../../user/clusters/applications.md#using-a-static-ip)
 1. [Use your own buildpacks to build your application](customize.md#custom-buildpacks)
 1. [Prometheus monitoring](../../user/project/integrations/prometheus.md)
--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@ -109,8 +109,8 @@ After all requirements are met, you can [enable Auto DevOps](index.md#enablingdi

 You can choose to target [AWS ECS](../../ci/cloud_deployment/index.md) as a deployment platform instead of using Kubernetes.

-To get started on Auto DevOps to AWS ECS, you must add a specific Environment
-Variable. To do so, follow these steps:
+To get started on Auto DevOps to AWS ECS, you must add a specific CI/CD variable.
+To do so, follow these steps:

 1. In your project, go to **Settings > CI / CD** and expand the **Variables**
   section.
@ -121,7 +121,7 @@ Variable. To do so, follow these steps:
   - `ECS` if you're not enforcing any launch type check when deploying to ECS.

 When you trigger a pipeline, if you have Auto DevOps enabled and if you have correctly
-[entered AWS credentials as environment variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
+[entered AWS credentials as variables](../../ci/cloud_deployment/index.md#deploy-your-application-to-the-aws-elastic-container-service-ecs),
 your application is deployed to AWS ECS.

 [GitLab Managed Apps](../../user/clusters/applications.md) are not available when deploying to AWS ECS.
@ -145,7 +145,7 @@ own pipeline, as the override stops working when the name changes.

 You can target [AWS EC2](../../ci/cloud_deployment/index.md)
 as a deployment platform instead of Kubernetes. To use Auto DevOps with AWS EC2, you must add a
-specific environment variable.
+specific CI/CD variable.

 For more details, see [Custom build job for Auto DevOps](../../ci/cloud_deployment/index.md#custom-build-job-for-auto-devops)
 for deployments to AWS EC2.
--- a/doc/topics/autodevops/stages.md
+++ b/doc/topics/autodevops/stages.md
@ -53,7 +53,7 @@ For the requirements of other languages and frameworks, read the

 NOTE:
 If Auto Build fails despite the project meeting the buildpack requirements, set
-a project variable `TRACE=true` to enable verbose logging, which may help you
+a project CI/CD variable `TRACE=true` to enable verbose logging, which may help you
 troubleshoot.

 ### Auto Build using Cloud Native Buildpacks (beta)
@ -62,9 +62,9 @@ troubleshoot.

 Auto Build supports building your application using [Cloud Native Buildpacks](https://buildpacks.io)
 through the [`pack` command](https://github.com/buildpacks/pack). To use Cloud Native Buildpacks,
-set the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
+set the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` to a non-empty
 value. The default builder is `heroku/buildpacks:18` but a different builder
-can be selected using the CI variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.
+can be selected using the CI/CD variable `AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDER`.

 Cloud Native Buildpacks (CNBs) are an evolution of Heroku buildpacks, and
 GitLab expects them to eventually supersede Herokuish-based builds within Auto DevOps. For more
@ -103,7 +103,9 @@ NOTE:
 Not all buildpacks supported by [Auto Build](#auto-build) are supported by Auto Test.
 Auto Test uses [Herokuish](https://gitlab.com/gitlab-org/gitlab/-/issues/212689), *not*
 Cloud Native Buildpacks, and only buildpacks that implement the
+<!-- vale gitlab.Spelling = NO -->
 [Testpack API](https://devcenter.heroku.com/articles/testpack-api) are supported.
+<!-- vale gitlab.Spelling = YES -->

 ### Currently supported languages

@ -284,7 +286,7 @@ see the documentation.
 ### Overriding the DAST target

 To use a custom target instead of the auto-deployed review apps,
-set a `DAST_WEBSITE` environment variable to the URL for DAST to scan.
+set a `DAST_WEBSITE` CI/CD variable to the URL for DAST to scan.

 WARNING:
 If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is
@ -297,10 +299,10 @@ data loss or corruption.

 You can disable DAST:

- On all branches by setting the `DAST_DISABLED` environment variable to `"true"`.
+- On all branches by setting the `DAST_DISABLED` CI/CD variable to `"true"`.
 - Only on the default branch by setting the `DAST_DISABLED_FOR_DEFAULT_BRANCH`
-  environment variable to `"true"`.
- Only on feature branches by setting `REVIEW_DISABLED` environment variable to
+  variable to `"true"`.
+- Only on feature branches by setting `REVIEW_DISABLED` variable to
  `"true"`. This also disables the Review App.

 ## Auto Browser Performance Testing **(PREMIUM)**
@ -336,7 +338,7 @@ uploads the report as an artifact.

 Some initial setup is required. A [k6](https://k6.io/) test needs to be
 written that's tailored to your specific application. The test also needs to be
-configured so it can pick up the environment's dynamic URL via an environment variable.
+configured so it can pick up the environment's dynamic URL via a CI/CD variable.

 Any load performance test result differences between the source and target branches are also
 [shown in the merge request widget](../../user/project/merge_requests/load_performance_testing.md).
@ -356,7 +358,7 @@ default, but the
 [Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml)
 contains job definitions for these tasks if you want to enable them.

-You can use [environment variables](customize.md#environment-variables) to automatically
+You can use [CI/CD variables](customize.md#cicd-variables) to automatically
 scale your pod replicas, and to apply custom arguments to the Auto DevOps `helm upgrade`
 commands. This is an easy way to
 [customize the Auto Deploy Helm chart](customize.md#custom-helm-chart).
@ -440,7 +442,7 @@ On GitLab 12.9 and 12.10, opting into
 `AUTO_DEVOPS_POSTGRES_CHANNEL` version `2` deletes the version `1` PostgreSQL
 database. Follow the [guide to upgrading PostgreSQL](upgrading_postgresql.md)
 to back up and restore your database before opting into version `2` (On
-GitLab 13.0, an additional variable is required to trigger the database
+GitLab 13.0, an additional CI/CD variable is required to trigger the database
 deletion).

 ### Migrations
@ -448,7 +450,7 @@ deletion).
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21955) in GitLab 11.4

 You can configure database initialization and migrations for PostgreSQL to run
-within the application pod by setting the project variables `DB_INITIALIZE` and
+within the application pod by setting the project CI/CD variables `DB_INITIALIZE` and
 `DB_MIGRATE` respectively.

 If present, `DB_INITIALIZE` is run as a shell command within an application pod
@ -500,7 +502,7 @@ access to a Redis instance. Auto DevOps doesn't deploy this instance for you, so
 you must:

 - Maintain your own Redis instance.
- Set a CI variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
+- Set a CI/CD variable `K8S_SECRET_REDIS_URL`, which is the URL of this instance,
  to ensure it's passed into your deployments.

 After configuring your worker to respond to health checks, run a Sidekiq
@ -686,5 +688,5 @@ You can follow the [code intelligence epic](https://gitlab.com/groups/gitlab-org
 for updates.

 This stage is enabled by default. You can disable it by adding the
-`CODE_INTELLIGENCE_DISABLED` environment variable. Read more about
+`CODE_INTELLIGENCE_DISABLED` CI/CD variable. Read more about
 [disabling Auto DevOps jobs](../../topics/autodevops/customize.md#disable-jobs).
--- a/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
+++ b/doc/topics/autodevops/upgrading_auto_deploy_dependencies.md
@ -114,7 +114,7 @@ If your Auto DevOps project has an active environment that was deployed with the
   job saves a backup for 1 week in a job artifact called `helm-2-release-backups`.
   The backup is in a Kubernetes manifest file that can be restored using
   `kubectl apply -f $backup`.
-1. Remove the `MIGRATE_HELM_2TO3` variable.
+1. Remove the `MIGRATE_HELM_2TO3` CI/CD variable.

 #### In-Cluster PostgreSQL Channel 2

@ -145,11 +145,11 @@ steps to upgrade to v2:
   them to `production` first to delete the unstable tracks.
 1. Verify your project is [using the v2 `auto-deploy-image`](#verify-dependency-versions).
   If not, [specify the version](#use-a-specific-version-of-auto-deploy-dependencies).
-1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable with a value of `true`
+1. Add an `AUTO_DEVOPS_FORCE_DEPLOY_V2` CI/CD variable with a value of `true`
   in the GitLab CI/CD settings.
 1. Create a new pipeline and run the `production` job to renew the resource architecture
   with the v2 `auto-deploy-app chart`.
-1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` environment variable.
+1. Remove the `AUTO_DEVOPS_FORCE_DEPLOY_V2` variable.

 ### Use a specific version of Auto Deploy dependencies

@ -167,7 +167,7 @@ include:
 ### Ignore warnings and continue deploying

 If you are certain that the new chart version is safe to be deployed, you can add
-the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [environment variable](customize.md#build-and-deployment)
+the `AUTO_DEVOPS_FORCE_DEPLOY_V<major-version-number>` [CI/CD variable](customize.md#build-and-deployment)
 to force the deployment to continue.

 For example, if you want to deploy the `v2.0.0` chart on a deployment that previously
--- a/doc/user/admin_area/index.md
+++ b/doc/user/admin_area/index.md
@ -203,7 +203,7 @@ sort order is by **Last created**.
 To search for groups by name, enter your criteria in the search field. The group search is case
 insensitive, and applies partial matching.

-To [Create a new group](../group/index.md#create-a-new-group) click **New group**.
+To [Create a new group](../group/index.md#create-a-group) click **New group**.

 ### Administering Jobs

--- a/doc/user/application_security/security_dashboard/index.md
+++ b/doc/user/application_security/security_dashboard/index.md
@ -175,7 +175,7 @@ lock files. Python projects can have lock files, but GitLab Secure tools don't s
 ## Security scans using Auto DevOps

 When using [Auto DevOps](../../../topics/autodevops/index.md), use
-[special environment variables](../../../topics/autodevops/customize.md#environment-variables)
+[special environment variables](../../../topics/autodevops/customize.md#cicd-variables)
 to configure daily security scans.

 <!-- ## Troubleshooting
--- a/doc/user/clusters/applications.md
+++ b/doc/user/clusters/applications.md
@ -372,7 +372,7 @@ For GitLab Runner to function, you _must_ specify the following:
 - `runnerRegistrationToken`: The registration token for adding new runners to GitLab.
  This must be [retrieved from your GitLab instance](../../ci/runners/README.md).

-These values can be specified using [CI variables](../../ci/variables/README.md):
+These values can be specified using [CI/CD variables](../../ci/variables/README.md):

 - `GITLAB_RUNNER_GITLAB_URL` is used for `gitlabUrl`.
 - `GITLAB_RUNNER_REGISTRATION_TOKEN` is used for `runnerRegistrationToken`
@ -730,7 +730,7 @@ Set:
 - "Redirect URI" to `http://<JupyterHub Host>/hub/oauth_callback`.
 - "Scope" to `api read_repository write_repository`.

-In addition, the following variables must be specified using [CI variables](../../ci/variables/README.md):
+In addition, the following variables must be specified using [CI/CD variables](../../ci/variables/README.md):

 - `JUPYTERHUB_PROXY_SECRET_TOKEN` - Secure string used for signing communications
  from the hub. Read [`proxy.secretToken`](https://zero-to-jupyterhub.readthedocs.io/en/stable/reference/reference.html#proxy-secrettoken).
--- a/doc/user/group/img/groups.png
+++ b/doc/user/group/img/groups.png
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@ -7,54 +7,34 @@ info: To determine the technical writer assigned to the Stage/Group associated w

 # Groups

-With GitLab Groups, you can:
+In GitLab, you can put related projects together in a group.

- Assemble related projects together.
- Grant members access to several projects at once.
+For example, you might create a group for your company members and a subgroup for each individual team.
+You can name the group `company-team`, and the subgroups `backend-team`, `frontend-team`, and `production-team`.

-For a video introduction to GitLab Groups, see [GitLab University: Repositories, Projects and Groups](https://www.youtube.com/watch?v=4TWfh1aKHHw).
+Then you can:

-Groups can also be nested in [subgroups](subgroups/index.md).
+- Grant members access to multiple projects at once.
+- Add to-do items for all of the group members at once.
+- View the [issues](../project/issues/index.md#issues-list) and
+  [merge requests](../project/merge_requests/reviewing_and_managing_merge_requests.md#view-merge-requests-for-all-projects-in-a-group)
+  for all projects in the group, together in a single list view.
+- [Bulk edit](../group/bulk_editing/index.md) issues, epics, and merge requests.

-Find your groups by clicking **Groups > Your Groups** in the top navigation.
+You can also create [subgroups](subgroups/index.md).

-![GitLab Groups](img/groups.png)
+## View groups

-> The **Groups** dropdown in the top navigation was [introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/36234) in [GitLab 11.1](https://about.gitlab.com/releases/2018/07/22/gitlab-11-1-released/#groups-dropdown-in-navigation).
+To view groups:

-The **Groups** page displays:
+1. In the top menu, select **Groups > Your Groups**. All groups you are a member of are displayed.
+1. To view a list of public groups, select **Explore public groups**.

- All groups you are a member of, when **Your groups** is selected.
- A list of public groups, when **Explore public groups** is selected.
+You can also view groups by namespace.

-Each group on the **Groups** page is listed with:
+### Namespaces

- How many subgroups it has.
- How many projects it contains.
- How many members the group has, not including members inherited from parent group(s).
- The group's visibility.
- A link to the group's settings, if you have sufficient permissions.
- A link to leave the group, if you are a member.
-
-## Use cases
-
-You can create groups for numerous reasons. To name a couple:
-
- Grant access to multiple projects and multiple team members in fewer steps by organizing related projects under the same [namespace](#namespaces) and adding members to the top-level group.
- Make it easier to `@mention` all of your team at once in issues and merge requests by creating a group and including the appropriate members.
-
-For example, you could create a group for your company members, and create a [subgroup](subgroups/index.md) for each individual team. Let's say you create a group called `company-team`, and you create subgroups in this group for the individual teams `backend-team`, `frontend-team`, and `production-team`.
-
- When you start a new implementation from an issue, you add a comment:
-  _"`@company-team`, let's do it! `@company-team/backend-team` you're good to go!"_
- When your backend team needs help from frontend, they add a comment:
-  _"`@company-team/frontend-team` could you help us here please?"_
- When the frontend team completes their implementation, they comment:
-  _"`@company-team/backend-team`, it's done! Let's ship it `@company-team/production-team`!"_
-
-## Namespaces
-
-In GitLab, a namespace is a unique name to be used as a user name, a group name, or a subgroup name.
+In GitLab, a namespace is a unique name and URL for a user, a group, or subgroup.

 - `http://gitlab.example.com/username`
 - `http://gitlab.example.com/groupname`
@ -62,35 +42,19 @@ In GitLab, a namespace is a unique name to be used as a user name, a group name,

 For example, consider a user named Alex:

-1. Alex creates an account on GitLab.com with the username `alex`;
-   their profile will be accessed under `https://gitlab.example.com/alex`
-1. Alex creates a group for their team with the group name `alex-team`;
-   the group and its projects will be accessed under `https://gitlab.example.com/alex-team`
-1. Alex creates a subgroup of `alex-team` with the subgroup name `marketing`;
-   this subgroup and its projects will be accessed under `https://gitlab.example.com/alex-team/marketing`
+1. Alex creates an account with the username `alex`: `https://gitlab.example.com/alex`
+1. Alex creates a group for their team with the group name `alex-team`.
+   The group and its projects are available at: `https://gitlab.example.com/alex-team`
+1. Alex creates a subgroup of `alex-team` with the subgroup name `marketing`.
+   The subgroup and its projects are available at: `https://gitlab.example.com/alex-team/marketing`

-By doing so:
+## Create a group

- Any team member mentions Alex with `@alex`
- Alex mentions everyone from their team with `@alex-team`
- Alex mentions only the marketing team with `@alex-team/marketing`
+NOTE:
+For a list of words that can not be used as group names, see
+[reserved names](../reserved_names.md).

-## Issues and merge requests within a group
-
-Issues and merge requests are part of projects. For a given group, you can view all of the
-[issues](../project/issues/index.md#issues-list) and [merge requests](../project/merge_requests/reviewing_and_managing_merge_requests.md#view-merge-requests-for-all-projects-in-a-group) across all projects in that group,
-together in a single list view.
-
-### Bulk editing issues and merge requests
-
-For details, see [bulk editing issues and merge requests](../group/bulk_editing/index.md).
-
-## Create a new group
-
-> For a list of words that are not allowed to be used as group names see the
-> [reserved names](../reserved_names.md).
-
-To create a new Group, either:
+To create a new group, either:

 - In the top menu, click **Groups** and then **Your Groups**, and click the green button **New group**.

@ -166,7 +130,7 @@ If you change your mind before your request is approved, just click the

 ![Withdraw access request button](img/withdraw_access_request_button.png)

-## Changing the owner of a group
+## Change the owner of a group

 Ownership of a group means at least one of its members has
 [Owner permission](../permissions.md#group-members-permissions). Groups must have at
@ -266,6 +230,18 @@ You can sort members by **Account**, **Access granted**, **Max role**, or **Last

 ![Group members sort](img/group_members_sort_13_7.png)

+## Mention a group in an issue or merge request
+
+When you mention a group in a comment, every member of the group gets a to-do item
+added to their To-do list.
+
+1. Open the MR or issue.
+1. In a comment, type `@` followed by the user, group, or subgroup namespace.
+   For example, `@alex`, `@alex-team`, or `@alex-team/marketing`.
+1. Select **Comment**.
+
+A to-do item is created for all the group and subgroup members.
+
 ## Changing the default branch protection of a group

 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/7583) in GitLab 12.9.
@ -520,7 +496,7 @@ the group's dashboard, and clicking **Settings**.
 ### General settings

 In addition to editing any settings you previously
-set when [creating the group](#create-a-new-group), you can also
+set when [creating the group](#create-a-group), you can also
 access further configurations for your group.

 #### Changing a group's path
--- a/doc/user/project/clusters/add_eks_clusters.md
+++ b/doc/user/project/clusters/add_eks_clusters.md
@ -326,7 +326,7 @@ If a default Storage Class doesn't already exist and is desired, follow Amazon's
 to create one.

 Alternatively, disable PostgreSQL by setting the project variable
-[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#environment-variables) to `false`.
+[`POSTGRES_ENABLED`](../../../topics/autodevops/customize.md#cicd-variables) to `false`.

 ### Deploy the app to EKS

--- a/doc/user/project/clusters/protect/container_host_security/quick_start_guide.md
+++ b/doc/user/project/clusters/protect/container_host_security/quick_start_guide.md
@ -15,7 +15,7 @@ applications through GMAv2 exclusively when using Container Network Security.
 The following steps are recommended to install and use Container Host Security through GitLab:

 1. [Install at least one runner and connect it to GitLab](https://docs.gitlab.com/runner/).
-1. [Create a group](../../../../group/#create-a-new-group).
+1. [Create a group](../../../../group/#create-a-group).
 1. [Connect a Kubernetes cluster to the group](../../add_remove_clusters.md).
 1. [Create a cluster management project and associate it with the Kubernetes cluster](../../../../clusters/management_project.md).

--- a/doc/user/project/clusters/protect/container_network_security/quick_start_guide.md
+++ b/doc/user/project/clusters/protect/container_network_security/quick_start_guide.md
@ -15,7 +15,7 @@ applications through GMAv2 exclusively when using Container Network Security.
 The following steps are recommended to install and use Container Network Security through GitLab:

 1. [Install at least one runner and connect it to GitLab](https://docs.gitlab.com/runner/).
-1. [Create a group](../../../../group/#create-a-new-group).
+1. [Create a group](../../../../group/#create-a-group).
 1. [Connect a Kubernetes cluster to the group](../../add_remove_clusters.md).
 1. [Create a cluster management project and associate it with the Kubernetes cluster](../../../../clusters/management_project.md).

--- a/doc/user/project/merge_requests/getting_started.md
+++ b/doc/user/project/merge_requests/getting_started.md
@ -122,13 +122,15 @@ Requesting a code review is an important part of contributing code. However, dec
 your code and asking for a review are no easy tasks. Using the "assignee" field for both authors and
 reviewers makes it hard for others to determine who's doing what on a merge request.

-GitLab Merge Request Reviewers easily allow authors to request a review as well as see the status of the
-review. By selecting one or more users from the **Reviewers** field in the merge request's right-hand
-sidebar, the assigned reviewers will receive a notification of the request to review the merge request.
+GitLab Merge Request Reviewers enable you to request a review of your work, and
+see the status of the review. Reviewers help distinguish the roles of the users
+involved in the merge request. In comparison to an **Assignee**, who is directly
+responsible for creating or merging a merge request, a **Reviewer** is a team member
+who may only be involved in one aspect of the merge request, such as a peer review.

-This makes it easy to determine the relevant roles for the users involved in the merge request, as well as formally requesting a review from a peer.
-
-To request it, open the **Reviewers** drop-down box to search for the user you wish to get a review from.
+To request a review of a merge request, expand the **Reviewers** select box in
+the right-hand sidebar. Search for the users you want to request a review from.
+When selected, GitLab creates a [to-do list item](../../todos.md) for each reviewer.

 #### Approval Rule information for Reviewers **(PREMIUM)**

--- a/doc/user/project/merge_requests/merge_request_approvals.md
+++ b/doc/user/project/merge_requests/merge_request_approvals.md
@ -138,14 +138,14 @@ to push or merge code to any branches.

 To enable this access:

-1. [Create a new group](../../group/index.md#create-a-new-group), and then
+1. [Create a new group](../../group/index.md#create-a-group), and then
   [add the user to the group](../../group/index.md#add-users-to-a-group),
   ensuring you select the Reporter role for the user.
 1. [Share the project with your group](../members/share_project_with_groups.md#sharing-a-project-with-a-group-of-users),
   based on the Reporter role.
 1. Navigate to your project's **Settings > General**, and in the
   **Merge request approvals** section, click **Expand**.
-1. [Add the group](../../group/index.md#create-a-new-group) to the permission list
+1. [Add the group](../../group/index.md#create-a-group) to the permission list
   for the protected branch.

 ![Update approval rule](img/update_approval_rule_v13_4.png)
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@ -20655,6 +20655,9 @@ msgstr ""
 msgid "OnCallSchedules|Create on-call schedules  in GitLab"
 msgstr ""

+msgid "OnCallSchedules|Currently no rotation."
+msgstr ""
+
 msgid "OnCallSchedules|Delete rotation"
 msgstr ""

--- a/qa/qa/page/component/issue_board/show.rb
+++ b/qa/qa/page/component/issue_board/show.rb
@ -43,6 +43,10 @@ module QA
            element :focus_mode_button
          end

+          view 'app/assets/javascripts/boards/components/config_toggle.vue' do
+            element :boards_config_button
+          end
+
          # The `focused_board` method does not use `find_element` with an element defined
          # with the attribute `data-qa-selector` since such element is not unique when the
          # `is-focused` class is not set, and it was not possible to find a better solution.
@ -82,6 +86,10 @@ module QA
            end
          end

+          def click_boards_config_button
+            click_element(:boards_config_button)
+          end
+
          def click_boards_dropdown_button
            # The dropdown button comes from the `GlDropdown` component of `@gitlab/ui`,
            # so it wasn't possible to add a `data-qa-selector` to it.
--- a/rubocop/rubocop-migrations.yml
+++ b/rubocop/rubocop-migrations.yml
@ -27,6 +27,7 @@ Migration/UpdateLargeTable:
    - :project_ci_cd_settings
    - :project_settings
    - :project_features
+    - :protected_branches
    - :push_event_payloads
    - :resource_label_events
    - :routes
--- a/spec/graphql/mutations/boards/update_spec.rb
+++ b/spec/graphql/mutations/boards/update_spec.rb
@ -0,0 +1,57 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe Mutations::Boards::Update do
+  let_it_be(:project) { create(:project) }
+  let_it_be(:user) { create(:user) }
+  let_it_be(:board) { create(:board, project: project) }
+
+  let(:mutation) { described_class.new(object: nil, context: { current_user: user }, field: nil) }
+  let(:mutated_board) { subject[:board] }
+
+  let(:mutation_params) do
+    {
+      id: board.to_global_id,
+      hide_backlog_list: true,
+      hide_closed_list: false
+    }
+  end
+
+  subject { mutation.resolve(**mutation_params) }
+
+  specify { expect(described_class).to require_graphql_authorizations(:admin_board) }
+
+  describe '#resolve' do
+    context 'when the user cannot admin the board' do
+      it 'raises an error' do
+        expect { subject }.to raise_error(Gitlab::Graphql::Errors::ResourceNotAvailable)
+      end
+    end
+
+    context 'with invalid params' do
+      it 'raises an error' do
+        mutation_params[:id] = project.to_global_id
+
+        expect { subject }.to raise_error(::GraphQL::CoercionError)
+      end
+    end
+
+    context 'when user can update board' do
+      before do
+        board.resource_parent.add_reporter(user)
+      end
+
+      it 'updates board with correct values' do
+        expected_attributes = {
+          hide_backlog_list: true,
+          hide_closed_list: false
+        }
+
+        subject
+
+        expect(board.reload).to have_attributes(expected_attributes)
+      end
+    end
+  end
+end
--- a/spec/models/list_spec.rb
+++ b/spec/models/list_spec.rb
@ -17,6 +17,19 @@ RSpec.describe List do
    it { is_expected.to validate_presence_of(:list_type) }
  end

+  describe '.without_types' do
+    it 'exclude lists of given types' do
+      board = create(:list, list_type: :label).board
+      # closed list is created by default
+      backlog_list = create(:list, list_type: :backlog, board: board)
+
+      exclude_type = [described_class.list_types[:label], described_class.list_types[:closed]]
+
+      lists = described_class.without_types(exclude_type)
+      expect(lists.where(board: board)).to match_array([backlog_list])
+    end
+  end
+
  describe '#update_preferences_for' do
    let(:user) { create(:user) }
    let(:list) { create(:list) }
--- a/spec/services/boards/lists/list_service_spec.rb
+++ b/spec/services/boards/lists/list_service_spec.rb
@ -8,6 +8,26 @@ RSpec.describe Boards::Lists::ListService do
  describe '#execute' do
    let(:service) { described_class.new(parent, user) }

+    shared_examples 'hidden lists' do
+      let!(:list) { create(:list, board: board, label: label) }
+
+      context 'when hide_backlog_list is true' do
+        it 'hides backlog list' do
+          board.update!(hide_backlog_list: true)
+
+          expect(service.execute(board)).to match_array([board.closed_list, list])
+        end
+      end
+
+      context 'when hide_closed_list is true' do
+        it 'hides closed list' do
+          board.update!(hide_closed_list: true)
+
+          expect(service.execute(board)).to match_array([board.backlog_list, list])
+        end
+      end
+    end
+
    context 'when board parent is a project' do
      let(:project) { create(:project) }
      let(:board) { create(:board, project: project) }
@ -16,6 +36,7 @@ RSpec.describe Boards::Lists::ListService do
      let(:parent) { project }

      it_behaves_like 'lists list service'
+      it_behaves_like 'hidden lists'
    end

    context 'when board parent is a group' do
@ -26,6 +47,7 @@ RSpec.describe Boards::Lists::ListService do
      let(:parent) { group }

      it_behaves_like 'lists list service'
+      it_behaves_like 'hidden lists'
    end
  end
 end