diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 54ce9f4956fb30a24aca1bb8875706d548e12d7f..eb112de1451118ac4354e4ed663ed23e993716ba 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,4 +1,4 @@
-image: "dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.4.5-golang-1.9-git-2.18-chrome-69.0-node-8.x-yarn-1.2-postgresql-9.6-graphicsmagick-1.3.29"
+image: "dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.5.3-golang-1.9-git-2.18-chrome-69.0-node-10.x-yarn-1.12-postgresql-9.6-graphicsmagick-1.3.29"
 
 .dedicated-runner: &dedicated-runner
   retry: 1
@@ -6,7 +6,7 @@ image: "dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.4.5-golang-1.9-git
     - gitlab-org
 
 .default-cache: &default-cache
-  key: "ruby-2.4.5-debian-stretch-with-yarn"
+  key: "debian-stretch-ruby-2.5.3-node-10.x"
   paths:
     - vendor/ruby
     - .yarn-cache/
@@ -121,7 +121,7 @@ stages:
   <<: *except-docs-and-qa
 
 .single-script-job: &single-script-job
-  image: ruby:2.4-alpine
+  image: ruby:2.5-alpine
   stage: test
   cache: {}
   dependencies: []
@@ -227,6 +227,8 @@ stages:
   script:
     - git fetch https://gitlab.com/gitlab-org/gitlab-ce.git v9.3.0
     - git checkout -f FETCH_HEAD
+    - sed -i "s/gem 'oj', '~> 2.17.4'//" Gemfile
+    - bundle update google-protobuf grpc
     - bundle install $BUNDLE_INSTALL_FLAGS
     - date
     - cp config/gitlab.yml.example config/gitlab.yml
@@ -316,7 +318,7 @@ review-docs-cleanup:
 # Trigger a docker image build in CNG (Cloud Native GitLab) repository
 #
 cloud-native-image:
-  image: ruby:2.4-alpine
+  image: ruby:2.5-alpine
   before_script: []
   dependencies: []
   stage: test
@@ -369,7 +371,7 @@ update-tests-metadata:
 
 flaky-examples-check:
   <<: *dedicated-runner
-  image: ruby:2.4-alpine
+  image: ruby:2.5-alpine
   services: []
   before_script: []
   variables:
@@ -589,7 +591,7 @@ static-analysis:
   script:
     - scripts/static-analysis
   cache:
-    key: "ruby-2.4.5-debian-stretch-with-yarn-and-rubocop"
+    key: "debian-stretch-ruby-2.5.3-node-10.x-and-rubocop"
     paths:
       - vendor/ruby
       - .yarn-cache/
@@ -696,7 +698,7 @@ gitlab:setup-mysql:
 # Frontend-related jobs
 gitlab:assets:compile:
   <<: *dedicated-no-docs-and-no-qa-pull-cache-job
-  image: dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.4.4-git-2.18-chrome-69.0-node-8.x-yarn-1.2-graphicsmagick-1.3.29-docker-18.06.1
+  image: dev.gitlab.org:5005/gitlab/gitlab-build-images:ruby-2.5.3-git-2.18-chrome-69.0-node-8.x-yarn-1.2-graphicsmagick-1.3.29-docker-18.06.1
   dependencies: []
   services:
     - docker:stable-dind
diff --git a/.nvmrc b/.nvmrc
index dba04c1e1786b2c5f953ebf2c24c6fcc615c2d9a..db24ab967fb52af99df9337d762d6ffe5efa6313 100644
--- a/.nvmrc
+++ b/.nvmrc
@@ -1 +1 @@
-8.11.3
+10.13.0
diff --git a/.ruby-version b/.ruby-version
index 59aa62c1fa4c234af19118ff8d8572c1d50437fd..aedc15bb0c6e24f27eedf7684532f8039cabb92c 100644
--- a/.ruby-version
+++ b/.ruby-version
@@ -1 +1 @@
-2.4.5
+2.5.3
diff --git a/app/assets/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer.vue b/app/assets/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer.vue
index e68a2aa73fabdfe56811e999d7cc0c96f2a5f68b..d7f24c1afc5480611ed10db63e5b9d5bfdf4073e 100644
--- a/app/assets/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer.vue
+++ b/app/assets/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer.vue
@@ -44,8 +44,11 @@ export default {
     isNew() {
       return this.diffMode === diffModes.new;
     },
+    isRenamed() {
+      return this.diffMode === diffModes.renamed;
+    },
     imagePath() {
-      return this.isNew ? this.newPath : this.oldPath;
+      return this.isNew || this.isRenamed ? this.newPath : this.oldPath;
     },
   },
   methods: {
@@ -114,7 +117,7 @@ export default {
           }]"
         >
           <slot
-            v-if="isNew"
+            v-if="isNew || isRenamed"
             slot="image-overlay"
             name="image-overlay"
           >
diff --git a/app/assets/javascripts/vue_shared/components/header_ci_component.vue b/app/assets/javascripts/vue_shared/components/header_ci_component.vue
index aee88cae48d3fed7ce21a778428cc6e02a570f4c..88e95c33b9b84f897fd5133cece648b8dedd0491 100644
--- a/app/assets/javascripts/vue_shared/components/header_ci_component.vue
+++ b/app/assets/javascripts/vue_shared/components/header_ci_component.vue
@@ -1,8 +1,9 @@
 <script>
+import { GlTooltipDirective, GlLink, GlButton } from '@gitlab-org/gitlab-ui';
 import CiIconBadge from './ci_badge_link.vue';
 import TimeagoTooltip from './time_ago_tooltip.vue';
-import tooltip from '../directives/tooltip';
 import UserAvatarImage from './user_avatar/user_avatar_image.vue';
+import LoadingButton from '~/vue_shared/components/loading_button.vue';
 
 /**
  * Renders header component for job and pipeline page based on UI mockups
@@ -16,9 +17,12 @@ export default {
     CiIconBadge,
     TimeagoTooltip,
     UserAvatarImage,
+    GlLink,
+    GlButton,
+    LoadingButton,
   },
   directives: {
-    tooltip,
+    GlTooltip: GlTooltipDirective,
   },
   props: {
     status: {
@@ -98,8 +102,8 @@ export default {
       by
 
       <template v-if="user">
-        <a
-          v-tooltip
+        <gl-link
+          v-gl-tooltip
           :href="user.path"
           :title="user.email"
           class="js-user-link commit-committer-link"
@@ -113,7 +117,7 @@ export default {
           />
 
           {{ user.name }}
-        </a>
+        </gl-link>
         <span
           v-if="user.status_tooltip_html"
           v-html="user.status_tooltip_html"></span>
@@ -127,16 +131,16 @@ export default {
       <template
         v-for="(action, i) in actions"
       >
-        <a
+        <gl-link
           v-if="action.type === 'link'"
           :key="i"
           :href="action.path"
           :class="action.cssClass"
         >
           {{ action.label }}
-        </a>
+        </gl-link>
 
-        <a
+        <gl-link
           v-else-if="action.type === 'ujs-link'"
           :key="i"
           :href="action.path"
@@ -145,31 +149,24 @@ export default {
           rel="nofollow"
         >
           {{ action.label }}
-        </a>
+        </gl-link>
 
-        <button
+        <loading-button
           v-else-if="action.type === 'button'"
           :key="i"
+          :loading="action.isLoading"
           :disabled="action.isLoading"
           :class="action.cssClass"
-          type="button"
+          container-class="d-inline"
+          :label="action.label"
           @click="onClickAction(action)"
-        >
-          {{ action.label }}
-          <i
-            v-show="action.isLoading"
-            class="fa fa-spin fa-spinner"
-            aria-hidden="true"
-          >
-          </i>
-        </button>
+        />
       </template>
     </section>
-    <button
+    <gl-button
       v-if="hasSidebarButton"
       id="toggleSidebar"
-      type="button"
-      class="btn btn-default d-block d-sm-none
+      class="d-block d-sm-none
 sidebar-toggle-btn js-sidebar-build-toggle js-sidebar-build-toggle-header"
       @click="onClickSidebarButton"
     >
@@ -179,6 +176,6 @@ sidebar-toggle-btn js-sidebar-build-toggle js-sidebar-build-toggle-header"
         aria-labelledby="toggleSidebar"
       >
       </i>
-    </button>
+    </gl-button>
   </header>
 </template>
diff --git a/app/assets/stylesheets/pages/issuable.scss b/app/assets/stylesheets/pages/issuable.scss
index 00b06aea89809baade6f85c4132788bf172d71ff..3aa79bf24669dff5d3018ef95ba0edd98668ec9d 100644
--- a/app/assets/stylesheets/pages/issuable.scss
+++ b/app/assets/stylesheets/pages/issuable.scss
@@ -47,12 +47,6 @@
       @extend .fixed-width-container;
     }
   }
-
-  .diffs {
-    .mr-version-controls {
-      @extend .fixed-width-container;
-    }
-  }
 }
 
 .issuable-details {
diff --git a/app/assets/stylesheets/pages/note_form.scss b/app/assets/stylesheets/pages/note_form.scss
index 855d73a9939f7d713da848ac438e956dda81fdab..45b921a2fbbe9ca54e309ac065487fd42f0aa615 100644
--- a/app/assets/stylesheets/pages/note_form.scss
+++ b/app/assets/stylesheets/pages/note_form.scss
@@ -176,8 +176,10 @@
   background-color: $white-light;
 }
 
-.discussion-form-container {
-  padding: $gl-padding-top $gl-padding $gl-padding;
+table {
+  .discussion-form-container {
+    padding: $gl-padding-top $gl-padding $gl-padding;
+  }
 }
 
 .discussion-notes .disabled-comment {
diff --git a/app/assets/stylesheets/pages/notes.scss b/app/assets/stylesheets/pages/notes.scss
index 1b957f6cc694bae148145cce2cdc494fed3a3db3..35e01c9c8077a121ffce51ba296a04f1d72491df 100644
--- a/app/assets/stylesheets/pages/notes.scss
+++ b/app/assets/stylesheets/pages/notes.scss
@@ -13,12 +13,32 @@ $note-form-margin-left: 72px;
   }
 }
 
+@mixin outline-comment() {
+  margin: $gl-padding;
+  border: 1px solid $border-color;
+  border-radius: $border-radius-default;
+}
+
 .note-wrapper {
   padding: $gl-padding;
+
+  &.outlined {
+    @include outline-comment();
+  }
 }
 
-.issuable-discussion {
-  .notes.timeline > .timeline-entry {
+.main-notes-list {
+  @include vertical-line(39px);
+}
+
+.notes {
+  display: block;
+  list-style: none;
+  margin: 0;
+  padding: 0;
+  position: relative;
+
+  &.timeline > .timeline-entry {
     border: 1px solid $border-color;
     border-radius: $border-radius-default;
     margin: $gl-padding 0;
@@ -51,18 +71,6 @@ $note-form-margin-left: 72px;
       border-top: 1px solid $border-color;
     }
   }
-}
-
-.main-notes-list {
-  @include vertical-line(36px);
-}
-
-.notes {
-  display: block;
-  list-style: none;
-  margin: 0;
-  padding: 0;
-  position: relative;
 
   > .note-discussion {
     .card {
@@ -71,10 +79,6 @@ $note-form-margin-left: 72px;
 
     li.note {
       border-bottom: 1px solid $border-color;
-
-      &:first-child {
-        border-radius: $border-radius-default $border-radius-default 0 0;
-      }
     }
   }
 
@@ -387,6 +391,7 @@ $note-form-margin-left: 72px;
     line-height: 42px;
     padding: 0 $gl-padding;
     border-top: 1px solid $border-color;
+    border-radius: 0;
 
     &:hover {
       background-color: $gray-light;
@@ -479,9 +484,7 @@ $note-form-margin-left: 72px;
   }
 
   .note-wrapper {
-    margin: $gl-padding;
-    border: 1px solid $border-color;
-    border-radius: $border-radius-default;
+    @include outline-comment();
   }
 
   .discussion-reply-holder {
@@ -491,6 +494,16 @@ $note-form-margin-left: 72px;
   }
 }
 
+.commit-diff {
+  .notes {
+    @include vertical-line(52px);
+  }
+
+  .discussion-reply-holder {
+    border-top: 1px solid $border-color;
+  }
+}
+
 .discussion-header,
 .note-header-info {
   a {
diff --git a/app/models/clusters/platforms/kubernetes.rb b/app/models/clusters/platforms/kubernetes.rb
index 9860abeecf7b443a2e6a80a3f5bd8fc302642661..3c5d7756eecaa26322e52c747ae42b3f2bac4bd6 100644
--- a/app/models/clusters/platforms/kubernetes.rb
+++ b/app/models/clusters/platforms/kubernetes.rb
@@ -173,9 +173,7 @@ module Clusters
         kubeclient = build_kube_client!
 
         kubeclient.get_pods(namespace: actual_namespace).as_json
-      rescue Kubeclient::HttpError => err
-        raise err unless err.error_code == 404
-
+      rescue Kubeclient::ResourceNotFoundError
         []
       end
 
diff --git a/app/models/concerns/mentionable.rb b/app/models/concerns/mentionable.rb
index 298d0d42d90ae9eca13d3ad15b448704c611408d..0d88b34fb48216bc43d6c1d9dd65a83cf6dde76b 100644
--- a/app/models/concerns/mentionable.rb
+++ b/app/models/concerns/mentionable.rb
@@ -97,9 +97,9 @@ module Mentionable
   # Allows heavy processing to be skipped
   def matches_cross_reference_regex?
     reference_pattern = if !project || project.default_issues_tracker?
-                          ReferenceRegexes::DEFAULT_PATTERN
+                          ReferenceRegexes.default_pattern
                         else
-                          ReferenceRegexes::EXTERNAL_PATTERN
+                          ReferenceRegexes.external_pattern
                         end
 
     self.class.mentionable_attrs.any? do |attr, _|
diff --git a/app/models/concerns/mentionable/reference_regexes.rb b/app/models/concerns/mentionable/reference_regexes.rb
index fe8fbb7118476fc66d9e81fb0964a5e66be7d28c..b8fb3f71925ba67bdc026af0b21cd4f27476dab7 100644
--- a/app/models/concerns/mentionable/reference_regexes.rb
+++ b/app/models/concerns/mentionable/reference_regexes.rb
@@ -2,6 +2,8 @@
 
 module Mentionable
   module ReferenceRegexes
+    extend Gitlab::Utils::StrongMemoize
+
     def self.reference_pattern(link_patterns, issue_pattern)
       Regexp.union(link_patterns,
                    issue_pattern,
@@ -15,16 +17,20 @@ module Mentionable
       ]
     end
 
-    DEFAULT_PATTERN = begin
-      issue_pattern = Issue.reference_pattern
-      link_patterns = Regexp.union([Issue, Commit, MergeRequest, Epic].map(&:link_reference_pattern).compact)
-      reference_pattern(link_patterns, issue_pattern)
+    def self.default_pattern
+      strong_memoize(:default_pattern) do
+        issue_pattern = Issue.reference_pattern
+        link_patterns = Regexp.union([Issue, Commit, MergeRequest, Epic].map(&:link_reference_pattern).compact)
+        reference_pattern(link_patterns, issue_pattern)
+      end
     end
 
-    EXTERNAL_PATTERN = begin
-      issue_pattern = IssueTrackerService.reference_pattern
-      link_patterns = URI.regexp(%w(http https))
-      reference_pattern(link_patterns, issue_pattern)
+    def self.external_pattern
+      strong_memoize(:external_pattern) do
+        issue_pattern = IssueTrackerService.reference_pattern
+        link_patterns = URI.regexp(%w(http https))
+        reference_pattern(link_patterns, issue_pattern)
+      end
     end
   end
 end
diff --git a/app/models/identity.rb b/app/models/identity.rb
index f5a13dbd6f2c3d46b9743c439ace0a698fad4fd8..d63dd43242612cca512fbe674dac3cd4f5f7093f 100644
--- a/app/models/identity.rb
+++ b/app/models/identity.rb
@@ -1,18 +1,14 @@
 # frozen_string_literal: true
 
 class Identity < ActiveRecord::Base
-  def self.uniqueness_scope
-    :provider
-  end
-
   include Sortable
   include CaseSensitivity
 
   belongs_to :user
 
   validates :provider, presence: true
-  validates :extern_uid, allow_blank: true, uniqueness: { scope: uniqueness_scope, case_sensitive: false }
-  validates :user_id, uniqueness: { scope: uniqueness_scope }
+  validates :extern_uid, allow_blank: true, uniqueness: { scope: UniquenessScopes.scopes, case_sensitive: false }
+  validates :user_id, uniqueness: { scope: UniquenessScopes.scopes }
 
   before_save :ensure_normalized_extern_uid, if: :extern_uid_changed?
   after_destroy :clear_user_synced_attributes, if: :user_synced_attributes_metadata_from_provider?
diff --git a/app/models/identity/uniqueness_scopes.rb b/app/models/identity/uniqueness_scopes.rb
new file mode 100644
index 0000000000000000000000000000000000000000..674b735903ffda85c00feb7df255260b7dd4cd34
--- /dev/null
+++ b/app/models/identity/uniqueness_scopes.rb
@@ -0,0 +1,11 @@
+# frozen_string_literal: true
+
+class Identity < ActiveRecord::Base
+  # This module and method are defined in a separate file to allow EE to
+  # redefine the `scopes` method before it is used in the `Identity` model.
+  module UniquenessScopes
+    def self.scopes
+      [:provider]
+    end
+  end
+end
diff --git a/app/models/project_services/issue_tracker_service.rb b/app/models/project_services/issue_tracker_service.rb
index a399982e5ec6ac38f0e2f117a3aedd13e7f18734..f54497fc6d81b53cbf6ba528b280f4525545ce41 100644
--- a/app/models/project_services/issue_tracker_service.rb
+++ b/app/models/project_services/issue_tracker_service.rb
@@ -9,7 +9,7 @@ class IssueTrackerService < Service
   # Override this method on services that uses different patterns
   # This pattern does not support cross-project references
   # The other code assumes that this pattern is a superset of all
-  # overridden patterns. See ReferenceRegexes::EXTERNAL_PATTERN
+  # overridden patterns. See ReferenceRegexes.external_pattern
   def self.reference_pattern(only_long: false)
     if only_long
       /(\b[A-Z][A-Z0-9_]*-)(?<issue>\d+)/
diff --git a/app/models/project_services/kubernetes_service.rb b/app/models/project_services/kubernetes_service.rb
index 3459ded7ccf4c926c66894cb7b96e74361491923..c52a531e5fe458c4492af41a464371a8516b3103 100644
--- a/app/models/project_services/kubernetes_service.rb
+++ b/app/models/project_services/kubernetes_service.rb
@@ -203,9 +203,7 @@ class KubernetesService < DeploymentService
     kubeclient = build_kube_client!
 
     kubeclient.get_pods(namespace: actual_namespace).as_json
-  rescue Kubeclient::HttpError => err
-    raise err unless err.error_code == 404
-
+  rescue Kubeclient::ResourceNotFoundError
     []
   end
 
diff --git a/app/models/shard.rb b/app/models/shard.rb
index 2fa22bd040c5454565cecd7e5dd551f2977a4a29..2e75bc91df07602685ed87de7c14ac2bcbc818f3 100644
--- a/app/models/shard.rb
+++ b/app/models/shard.rb
@@ -9,13 +9,12 @@ class Shard < ActiveRecord::Base
 
     # The GitLab config does not change for the lifecycle of the process
     in_config = Gitlab.config.repositories.storages.keys.map(&:to_s)
+    in_db = all.pluck(:name)
 
-    transaction do
-      in_db = all.pluck(:name)
-      missing = in_config - in_db
-
-      missing.map { |name| by_name(name) }
-    end
+    # This may race with other processes creating shards at the same time, but
+    # `by_name` will handle that correctly
+    missing = in_config - in_db
+    missing.map { |name| by_name(name) }
   end
 
   def self.by_name(name)
diff --git a/app/services/clusters/applications/check_installation_progress_service.rb b/app/services/clusters/applications/check_installation_progress_service.rb
index 19dc0478591ebe099c298583cfb1f2dd05b1c2e9..49b8825c3a46714fbba0433b31bf6bb5a168ee89 100644
--- a/app/services/clusters/applications/check_installation_progress_service.rb
+++ b/app/services/clusters/applications/check_installation_progress_service.rb
@@ -15,8 +15,8 @@ module Clusters
           check_timeout
         end
       rescue Kubeclient::HttpError => e
-        Rails.logger.error "Kubernetes error: #{e.class.name} #{e.message}"
-        app.make_errored!("Kubernetes error") unless app.errored?
+        Rails.logger.error("Kubernetes error: #{e.error_code} #{e.message}")
+        app.make_errored!("Kubernetes error: #{e.error_code}") unless app.errored?
       end
 
       private
@@ -53,7 +53,7 @@ module Clusters
       def remove_installation_pod
         helm_api.delete_pod!(install_command.pod_name)
       rescue => e
-        Rails.logger.error "Kubernetes error: #{e.class.name} #{e.message}"
+        Rails.logger.error("Kubernetes error: #{e.class.name} #{e.message}")
         # no-op
       end
 
diff --git a/app/services/clusters/applications/install_service.rb b/app/services/clusters/applications/install_service.rb
index 5a24d78e7121403ae3df85b67272bcaa3c716293..947d22022bca757a7265a92b299e6bf81159a87b 100644
--- a/app/services/clusters/applications/install_service.rb
+++ b/app/services/clusters/applications/install_service.rb
@@ -13,8 +13,8 @@ module Clusters
           ClusterWaitForAppInstallationWorker.perform_in(
             ClusterWaitForAppInstallationWorker::INTERVAL, app.name, app.id)
         rescue Kubeclient::HttpError => e
-          Rails.logger.error "Kubernetes error: #{e.class.name} #{e.message}"
-          app.make_errored!("Kubernetes error.")
+          Rails.logger.error("Kubernetes error: #{e.error_code} #{e.message}")
+          app.make_errored!("Kubernetes error: #{e.error_code}")
         rescue StandardError => e
           Rails.logger.error "Can't start installation process: #{e.class.name} #{e.message}"
           app.make_errored!("Can't start installation process.")
diff --git a/app/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service.rb b/app/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service.rb
index 277cc4b788d3bcbc826faf909606af0b14b3efbf..4ad04ab801eec61bb6a1080dcfb0e7723253755a 100644
--- a/app/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service.rb
+++ b/app/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service.rb
@@ -21,10 +21,7 @@ module Clusters
 
         def get_secret
           kubeclient.get_secret(service_account_token_name, namespace).as_json
-        rescue Kubeclient::HttpError => err
-          raise err unless err.error_code == 404
-
-          nil
+        rescue Kubeclient::ResourceNotFoundError
         end
       end
     end
diff --git a/app/views/admin/application_settings/_ci_cd.html.haml b/app/views/admin/application_settings/_ci_cd.html.haml
index adb496495d11d60d976a737686dfc43b951d5a15..0d42094fc8993a7478135b0598e435abbf706cca 100644
--- a/app/views/admin/application_settings/_ci_cd.html.haml
+++ b/app/views/admin/application_settings/_ci_cd.html.haml
@@ -42,12 +42,12 @@
         <code>4 mins 2 sec</code>, <code>2h42min</code>.
         = link_to icon('question-circle'), help_page_path('user/admin_area/settings/continuous_integration', anchor: 'default-artifacts-expiration')
     .form-group
-      = f.label :archive_builds_in_human_readable, 'Archive builds in', class: 'label-bold'
+      = f.label :archive_builds_in_human_readable, 'Archive jobs', class: 'label-bold'
       = f.text_field :archive_builds_in_human_readable, class: 'form-control', placeholder: 'never'
       .form-text.text-muted
-        Set the duration when build gonna be considered old. Archived builds cannot be retried.
-        Make it empty to never expire builds. It has to be larger than 1 day.
-        The default unit is in seconds, but you can define an alternative. For example:
-        <code>4 mins 2 sec</code>, <code>2h42min</code>.
+        Set the duration for which the jobs will be considered as old and expired.
+        Once that time passes, the jobs will be archived and no longer able to be
+        retried. Make it empty to never expire jobs. It has to be no less than 1 day,
+        for example: <code>15 days</code>, <code>1 month</code>, <code>2 years</code>.
 
   = f.submit 'Save changes', class: "btn btn-success"
diff --git a/app/views/projects/diffs/_text_file.html.haml b/app/views/projects/diffs/_text_file.html.haml
index e8a5e63e59e37ec05cdd99a0b881a7c5a5db1f71..bc9f6c71fa80064c2e4f91da489bf7afe656aac3 100644
--- a/app/views/projects/diffs/_text_file.html.haml
+++ b/app/views/projects/diffs/_text_file.html.haml
@@ -3,7 +3,7 @@
   .suppressed-container
     %a.show-suppressed-diff.js-show-suppressed-diff Changes suppressed. Click to show.
 
-%table.text-file.diff-wrap-lines.code.js-syntax-highlight{ data: diff_view_data, class: too_big ? 'hide' : '' }
+%table.text-file.diff-wrap-lines.code.js-syntax-highlight.commit-diff{ data: diff_view_data, class: too_big ? 'hide' : '' }
   = render partial: "projects/diffs/line",
     collection: diff_file.highlighted_diff_lines,
     as: :line,
diff --git a/app/views/projects/merge_requests/_mr_title.html.haml b/app/views/projects/merge_requests/_mr_title.html.haml
index 1bf42ded97a3290b1512ab0a6970aa3bf056f3af..3cd83feb842b2f48eaf43831f2c97cc5a478a047 100644
--- a/app/views/projects/merge_requests/_mr_title.html.haml
+++ b/app/views/projects/merge_requests/_mr_title.html.haml
@@ -37,6 +37,6 @@
               = link_to 'Reopen', merge_request_path(@merge_request, merge_request: { state_event: :reopen }), method: :put, class: 'reopen-mr-link', title: 'Reopen merge request'
 
       - if can_update_merge_request
-        = link_to 'Edit', edit_project_merge_request_path(@project, @merge_request), class: "d-none d-sm-none d-md-block btn btn-grouped js-issuable-edit"
+        = link_to 'Edit', edit_project_merge_request_path(@project, @merge_request), class: "d-none d-sm-none d-md-block btn btn-grouped js-issuable-edit qa-edit-button"
 
       = render 'shared/issuable/close_reopen_button', issuable: @merge_request, can_update: can_update_merge_request, can_reopen: can_update_merge_request
diff --git a/app/views/shared/notes/_note.html.haml b/app/views/shared/notes/_note.html.haml
index 84adbd444c5d243b5603f7e7a526b6d27487b078..bc91843082375b05d36862e4f24503b1833c2cc0 100644
--- a/app/views/shared/notes/_note.html.haml
+++ b/app/views/shared/notes/_note.html.haml
@@ -5,7 +5,7 @@
 - note_editable = can?(current_user, :admin_note, note)
 - note_counter = local_assigns.fetch(:note_counter, 0)
 
-%li.timeline-entry{ id: dom_id(note),
+%li.timeline-entry.note-wrapper.outlined{ id: dom_id(note),
   class: ["note", "note-row-#{note.id}", ('system-note' if note.system)],
   data: { author_id: note.author.id,
     editable: note_editable,
diff --git a/app/views/shared/notes/_notes_with_form.html.haml b/app/views/shared/notes/_notes_with_form.html.haml
index ec1e10bb0c16a394911a6bb249775e033378ca3b..4c4050c605448bf97285a7e262e5f2922026cd03 100644
--- a/app/views/shared/notes/_notes_with_form.html.haml
+++ b/app/views/shared/notes/_notes_with_form.html.haml
@@ -8,7 +8,7 @@
 
 - if can_create_note?
   .notes.notes-form.timeline
-    .timeline-entry
+    .timeline-entry.note-form
       .timeline-entry-inner
         .flash-container.timeline-content
 
diff --git a/changelogs/unreleased/53972-fix-fill-shards.yml b/changelogs/unreleased/53972-fix-fill-shards.yml
new file mode 100644
index 0000000000000000000000000000000000000000..ca94d6cc5897d344c469689e724361405daa4687
--- /dev/null
+++ b/changelogs/unreleased/53972-fix-fill-shards.yml
@@ -0,0 +1,5 @@
+---
+title: Fix a race condition intermittently breaking GitLab startup
+merge_request: 23028
+author:
+type: fixed
diff --git a/changelogs/unreleased/kubernetes-http-response-code.yml b/changelogs/unreleased/kubernetes-http-response-code.yml
new file mode 100644
index 0000000000000000000000000000000000000000..551fe2edc3c0a32d34478a1c34c2c74009ddb709
--- /dev/null
+++ b/changelogs/unreleased/kubernetes-http-response-code.yml
@@ -0,0 +1,5 @@
+---
+title: Show HTTP response code for Kubernetes errors
+merge_request: 22964
+author:
+type: other
diff --git a/changelogs/unreleased/sh-bump-ruby-2-5-3.yml b/changelogs/unreleased/sh-bump-ruby-2-5-3.yml
new file mode 100644
index 0000000000000000000000000000000000000000..13cadc73e9c455b2efedb89de9ce9e34fbc83d6c
--- /dev/null
+++ b/changelogs/unreleased/sh-bump-ruby-2-5-3.yml
@@ -0,0 +1,5 @@
+---
+title: Upgrade to Ruby 2.5.3
+merge_request: 2806
+author:
+type: performance
diff --git a/doc/administration/auth/authentiq.md b/doc/administration/auth/authentiq.md
index 252ff1f4b15431e220b1e333b0662bf0607befde..772e55cef07c913738674f25b95edf32bfb3956d 100644
--- a/doc/administration/auth/authentiq.md
+++ b/doc/administration/auth/authentiq.md
@@ -6,7 +6,7 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
 
 1. Get your Client credentials (Client ID and Client Secret) at [Authentiq](https://www.authentiq.com/developers).
 
-2. On your GitLab server, open the configuration file:
+1. On your GitLab server, open the configuration file:
 
     For omnibus installation
     ```sh
@@ -18,11 +18,11 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
     ```sh
     sudo -u git -H editor /home/git/gitlab/config/gitlab.yml
     ```
-    
-3. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings to enable single sign-on and add Authentiq as an OAuth provider. 
 
-4. Add the provider configuration for Authentiq:
-    
+1. See [Initial OmniAuth Configuration](../../integration/omniauth.md#initial-omniauth-configuration) for initial settings to enable single sign-on and add Authentiq as an OAuth provider.
+
+1. Add the provider configuration for Authentiq:
+
     For Omnibus packages:
 
     ```ruby
@@ -31,15 +31,15 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
         "name" => "authentiq",
         "app_id" => "YOUR_CLIENT_ID",
         "app_secret" => "YOUR_CLIENT_SECRET",
-        "args" => { 
+        "args" => {
                "scope": 'aq:name email~rs address aq:push'
          }
       }
     ]
     ```
-    
+
     For installations from source:
-    
+
     ```yaml
     - { name: 'authentiq',
         app_id: 'YOUR_CLIENT_ID',
@@ -49,20 +49,20 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t
               }
       }
     ```
-    
-    
-5. The `scope` is set to request the user's name, email (required and signed), and permission to send push notifications to sign in on subsequent visits.
+
+
+1. The `scope` is set to request the user's name, email (required and signed), and permission to send push notifications to sign in on subsequent visits.
 See [OmniAuth Authentiq strategy](https://github.com/AuthentiqID/omniauth-authentiq/wiki/Scopes,-callback-url-configuration-and-responses) for more information on scopes and modifiers.
 
-6. Change `YOUR_CLIENT_ID` and `YOUR_CLIENT_SECRET` to the Client credentials you received in step 1.
+1. Change `YOUR_CLIENT_ID` and `YOUR_CLIENT_SECRET` to the Client credentials you received in step 1.
 
-7. Save the configuration file.
+1. Save the configuration file.
 
-8. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
+1. [Reconfigure](../restart_gitlab.md#omnibus-gitlab-reconfigure) or [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
 
-On the sign in page there should now be an Authentiq icon below the regular sign in form. Click the icon to begin the authentication process. 
+On the sign in page there should now be an Authentiq icon below the regular sign in form. Click the icon to begin the authentication process.
 
-- If the user has the Authentiq ID app installed in their iOS or Android device, they can scan the QR code, decide what personal details to share and sign in to your GitLab installation. 
-- If not they will be prompted to download the app and then follow the procedure above. 
+- If the user has the Authentiq ID app installed in their iOS or Android device, they can scan the QR code, decide what personal details to share and sign in to your GitLab installation.
+- If not they will be prompted to download the app and then follow the procedure above.
 
-If everything goes right, the user will be returned to GitLab and will be signed in.
\ No newline at end of file
+If everything goes right, the user will be returned to GitLab and will be signed in.
diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md
index 481eb6926748cfa88f5491c1f8fe8ae1e7837ad6..74b0e2c8184861eaf1b9574820e53d9d43a4970c 100644
--- a/doc/administration/high_availability/nfs.md
+++ b/doc/administration/high_availability/nfs.md
@@ -59,7 +59,7 @@ on an Linux NFS server, do the following:
     sysctl -w fs.leases-enable=0
     ```
 
-2. Restart the NFS server process. For example, on CentOS run `service nfs restart`.
+1. Restart the NFS server process. For example, on CentOS run `service nfs restart`.
 
 ## Avoid using AWS's Elastic File System (EFS)
 
@@ -87,12 +87,12 @@ this configuration.
 Additionally, this configuration is specifically warned against in the
 [Postgres Documentation](https://www.postgresql.org/docs/current/static/creating-cluster.html#CREATING-CLUSTER-NFS):
 
->PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like 
->locally-connected drives. If the client or server NFS implementation does not provide standard file 
->system semantics, this can cause reliability problems. Specifically, delayed (asynchronous) writes 
+>PostgreSQL does nothing special for NFS file systems, meaning it assumes NFS behaves exactly like
+>locally-connected drives. If the client or server NFS implementation does not provide standard file
+>system semantics, this can cause reliability problems. Specifically, delayed (asynchronous) writes
 >to the NFS server can cause data corruption problems.
 
-For supported database architecture, please see our documentation on 
+For supported database architecture, please see our documentation on
 [Configuring a Database for GitLab HA](https://docs.gitlab.com/ee/administration/high_availability/database.html).
 
 ## NFS Client mount options
diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md
index dcee57def74aff65b67c85942ac7a807597e1bf9..7c1ef43499d0c102967d77cadcf2aaedbb638111 100644
--- a/doc/administration/high_availability/redis.md
+++ b/doc/administration/high_availability/redis.md
@@ -665,7 +665,7 @@ cache, queues, and shared_state. To make this work with Sentinel:
     **Note**: Redis URLs should be in the format: `redis://:PASSWORD@SENTINEL_MASTER_NAME`
 
     1. PASSWORD is the plaintext password for the Redis instance
-    2. SENTINEL_MASTER_NAME is the Sentinel master name (e.g. `gitlab-redis-cache`)
+    1. SENTINEL_MASTER_NAME is the Sentinel master name (e.g. `gitlab-redis-cache`)
 1. Include an array of hashes with host/port combinations, such as the following:
 
     ```ruby
diff --git a/doc/administration/logs.md b/doc/administration/logs.md
index 038e043281caf18b47347fb06e2dd6a913b46791..7e5a3eb9ccd4329686158e3769086955194c282e 100644
--- a/doc/administration/logs.md
+++ b/doc/administration/logs.md
@@ -29,9 +29,9 @@ Each line contains a JSON line that can be ingested by Elasticsearch, Splunk, et
 In this example, you can see this was a GET request for a specific issue. Notice each line also contains performance data:
 
 1. `duration`: the total time taken to retrieve the request
-2. `view`: total time taken inside the Rails views
-3. `db`: total time to retrieve data from the database
-4. `gitaly_calls`: total number of calls made to Gitaly
+1. `view`: total time taken inside the Rails views
+1. `db`: total time to retrieve data from the database
+1. `gitaly_calls`: total number of calls made to Gitaly
 
 User clone/fetch activity using http transport appears in this log as `action: git_upload_pack`.
 
@@ -119,7 +119,7 @@ This file lives in `/var/log/gitlab/gitlab-rails/integrations_json.log` for
 Omnibus GitLab packages or in `/home/git/gitlab/log/integrations_json.log` for
 installations from source.
 
-It contains information about [integrations](../user/project/integrations/project_services.md) activities such as JIRA, Asana and Irker services. It uses JSON format like the example below:  
+It contains information about [integrations](../user/project/integrations/project_services.md) activities such as JIRA, Asana and Irker services. It uses JSON format like the example below:
 
 ``` json
 {"severity":"ERROR","time":"2018-09-06T14:56:20.439Z","service_class":"JiraService","project_id":8,"project_path":"h5bp/html5-boilerplate","message":"Error sending message","client_url":"http://jira.gitlap.com:8080","error":"execution expired"}
@@ -257,8 +257,8 @@ importer. Future importers may use this file.
 
 ## Reconfigure Logs
 
-Reconfigure log files live in `/var/log/gitlab/reconfigure` for Omnibus GitLab 
-packages. Installations from source don't have reconfigure logs. A reconfigure log 
+Reconfigure log files live in `/var/log/gitlab/reconfigure` for Omnibus GitLab
+packages. Installations from source don't have reconfigure logs. A reconfigure log
 is populated whenever `gitlab-ctl reconfigure` is run manually or as part of an upgrade.
 
 Reconfigure logs files are named according to the UNIX timestamp of when the reconfigure
diff --git a/doc/administration/monitoring/performance/influxdb_configuration.md b/doc/administration/monitoring/performance/influxdb_configuration.md
index c30cd2950d861bed573cfde89b35366ace2b3b24..fa281f47ed8b3ad80233271bcb18a26918a48f20 100644
--- a/doc/administration/monitoring/performance/influxdb_configuration.md
+++ b/doc/administration/monitoring/performance/influxdb_configuration.md
@@ -95,10 +95,10 @@ UDP can be done using the following settings:
 This does the following:
 
 1. Enable UDP and bind it to port 8089 for all addresses.
-2. Store any data received in the "gitlab" database.
-3. Define a batch of points to be 1000 points in size and allow a maximum of
+1. Store any data received in the "gitlab" database.
+1. Define a batch of points to be 1000 points in size and allow a maximum of
    5 batches _or_ flush them automatically after 1 second.
-4. Define a UDP read buffer size of 200 MB.
+1. Define a UDP read buffer size of 200 MB.
 
 One of the most important settings here is the UDP read buffer size as if this
 value is set too low, packets will be dropped. You must also make sure the OS
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index eada7b19dcdf05b4dca25bce1a0af4c2a45f4676..c293df3fc5721c03de311b7c34766f9316410b16 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -5,7 +5,7 @@ NOTE: **Note:** This document describes a drop-in replacement for the
 using [ssh certificates](ssh_certificates.md), they are even faster,
 but are not a drop-in replacement.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/1631) in 
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-ee/issues/1631) in
 > [GitLab Starter](https://about.gitlab.com/gitlab-ee) 9.3.
 >
 > [Available in](https://gitlab.com/gitlab-org/gitlab-ee/issues/3953) GitLab
@@ -109,7 +109,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
     yum install rpm-build gcc make wget openssl-devel krb5-devel pam-devel libX11-devel xmkmf libXt-devel
     ```
 
-3. Prepare the build by copying files to the right place:
+1. Prepare the build by copying files to the right place:
 
     ```
     mkdir -p /root/rpmbuild/{SOURCES,SPECS}
@@ -118,7 +118,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
     cd /root/rpmbuild/SPECS
     ```
 
-3. Next, set the spec settings properly:
+1. Next, set the spec settings properly:
 
     ```
     sed -i -e "s/%define no_gnome_askpass 0/%define no_gnome_askpass 1/g" openssh.spec
@@ -126,13 +126,13 @@ the database. The following instructions can be used to build OpenSSH 7.5:
     sed -i -e "s/BuildPreReq/BuildRequires/g" openssh.spec
     ```
 
-3. Build the RPMs:
+1. Build the RPMs:
 
     ```
     rpmbuild -bb openssh.spec
     ```
 
-4. Ensure the RPMs were built:
+1. Ensure the RPMs were built:
 
     ```
     ls -al /root/rpmbuild/RPMS/x86_64/
@@ -150,7 +150,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
     -rw-r--r--. 1 root root 367516 Jun 20 19:37 openssh-server-7.5p1-1.x86_64.rpm
     ```
 
-5. Install the packages. OpenSSH packages will replace `/etc/pam.d/sshd`
+1. Install the packages. OpenSSH packages will replace `/etc/pam.d/sshd`
    with its own version, which may prevent users from logging in, so be sure
    that the file is backed up and restored after installation:
 
@@ -161,7 +161,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
     yes | cp pam-ssh-conf-$timestamp /etc/pam.d/sshd
     ```
 
-6. Verify the installed version. In another window, attempt to login to the server:
+1. Verify the installed version. In another window, attempt to login to the server:
 
     ```
     ssh -v <your-centos-machine>
@@ -171,7 +171,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
 
     If not, you may need to restart sshd (e.g. `systemctl restart sshd.service`).
 
-7.  *IMPORTANT!* Open a new SSH session to your server before exiting to make
+1.  *IMPORTANT!* Open a new SSH session to your server before exiting to make
     sure everything is working! If you need to downgrade, simple install the
     older package:
 
diff --git a/doc/administration/reply_by_email_postfix_setup.md b/doc/administration/reply_by_email_postfix_setup.md
index d1a032195428086c9c895c93bcf4022323c19810..4c42cb7756aeb234f916c35063d336052b58ffab 100644
--- a/doc/administration/reply_by_email_postfix_setup.md
+++ b/doc/administration/reply_by_email_postfix_setup.md
@@ -8,7 +8,7 @@ The instructions make the assumption that you will be using the email address `i
 ## Configure your server firewall
 
 1. Open up port 25 on your server so that people can send email into the server over SMTP.
-2. If the mail server is different from the server running GitLab, open up port 143 on your server so that GitLab can read email from the server over IMAP.
+1. If the mail server is different from the server running GitLab, open up port 143 on your server so that GitLab can read email from the server over IMAP.
 
 ## Install packages
 
diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md
index 2902af8c782dc3bf6a7044408250b763f662031a..643c5b9fe804b2e5b4f514450ad810e7a21c6971 100644
--- a/doc/administration/troubleshooting/debug.md
+++ b/doc/administration/troubleshooting/debug.md
@@ -20,7 +20,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
     bundle exec rails console production
     ```
 
-2. Look at the ActionMailer `delivery_method` to make sure it matches what you
+1. Look at the ActionMailer `delivery_method` to make sure it matches what you
    intended. If you configured SMTP, it should say `:smtp`. If you're using
    Sendmail, it should say `:sendmail`:
 
@@ -29,7 +29,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
     => :smtp
     ```
 
-3. If you're using SMTP, check the mail settings:
+1. If you're using SMTP, check the mail settings:
 
     ```ruby
     irb(main):002:0> ActionMailer::Base.smtp_settings
@@ -39,7 +39,7 @@ an SMTP server, but you're not seeing mail delivered. Here's how to check the se
     In the example above, the SMTP server is configured for the local machine. If this is intended, you may need to check your local mail
     logs (e.g. `/var/log/mail.log`) for more details.
 
-4.  Send a test message via the console.
+1.  Send a test message via the console.
 
     ```ruby
     irb(main):003:0> Notify.test_email('youremail@email.com', 'Hello World', 'This is a test message').deliver_now
diff --git a/doc/ci/autodeploy/quick_start_guide.md b/doc/ci/autodeploy/quick_start_guide.md
index 3836216e95145dadbe97929d4a51dd5656f12e17..1473703542d5ee1e75c4b2da0675deb8d6ae361d 100644
--- a/doc/ci/autodeploy/quick_start_guide.md
+++ b/doc/ci/autodeploy/quick_start_guide.md
@@ -23,9 +23,9 @@ You need to have the Google Cloud SDK installed. e.g.
 On OSX, install [homebrew](https://brew.sh):
 
 1. Install Brew Caskroom: `brew install caskroom/cask/brew-cask`
-2. Install Google Cloud SDK: `brew cask install google-cloud-sdk`
-3. Add `kubectl`: `gcloud components install kubectl`
-4. Log in: `gcloud auth login`
+1. Install Google Cloud SDK: `brew cask install google-cloud-sdk`
+1. Add `kubectl`: `gcloud components install kubectl`
+1. Log in: `gcloud auth login`
 
 Now go back to the Google interface, find your cluster, and follow the instructions under `Connect to the cluster` and open the Kubernetes Dashboard. It will look something like `gcloud container clusters get-credentials ruby-autodeploy \ --zone europe-west2-c --project api-project-XXXXXXX` and then `kubectl proxy`.
 
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 3b41036cd1464f0e5d25ac1c75e0cffb0e6f9e1e..fef367051bfeb5773aa42f6355f6b5b0de166e41 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -46,18 +46,18 @@ GitLab Runner then executes job scripts as the `gitlab-runner` user.
       --description "My Runner"
     ```
 
-2. Install Docker Engine on server.
+1. Install Docker Engine on server.
 
     For more information how to install Docker Engine on different systems
     checkout the [Supported installations](https://docs.docker.com/engine/installation/).
 
-3. Add `gitlab-runner` user to `docker` group:
+1. Add `gitlab-runner` user to `docker` group:
 
     ```bash
     sudo usermod -aG docker gitlab-runner
     ```
 
-4. Verify that `gitlab-runner` has access to Docker:
+1. Verify that `gitlab-runner` has access to Docker:
 
     ```bash
     sudo -u gitlab-runner -H docker info
@@ -75,7 +75,7 @@ GitLab Runner then executes job scripts as the `gitlab-runner` user.
         - docker run my-docker-image /script/to/run/tests
     ```
 
-5. You can now use `docker` command and install `docker-compose` if needed.
+1. You can now use `docker` command and install `docker-compose` if needed.
 
 NOTE: **Note:**
 By adding `gitlab-runner` to the `docker` group you are effectively granting `gitlab-runner` full root permissions.
diff --git a/doc/ci/examples/browser_performance.md b/doc/ci/examples/browser_performance.md
index d36e97ebfd3e63dae0f6ba017234d12872f66add..7c3b3a65675adaaf7a011d8f5b15d2bcaa8f68ae 100644
--- a/doc/ci/examples/browser_performance.md
+++ b/doc/ci/examples/browser_performance.md
@@ -1,14 +1,20 @@
 # Browser Performance Testing with the Sitespeed.io container
 
+CAUTION: **Caution:**
+The job definition shown below is supported on GitLab 11.5 and later versions.
+It also requires the GitLab Runner 11.5 or later.
+For earlier versions, use the [previous job definitions](#previous-job-definitions).
+
 This example shows how to run the
 [Sitespeed.io container](https://hub.docker.com/r/sitespeedio/sitespeed.io/) on
 your code by using GitLab CI/CD and [Sitespeed.io](https://www.sitespeed.io)
 using Docker-in-Docker.
 
-First, you need a GitLab Runner with the
+First, you need GitLab Runner with
 [docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
-Once you set up the Runner, add a new job to `.gitlab-ci.yml`, called
-`performance`:
+
+Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
+generates the expected report:
 
 ```yaml
 performance:
@@ -26,19 +32,22 @@ performance:
     - mv sitespeed-results/data/performance.json performance.json
   artifacts:
     paths:
-    - performance.json
-    - sitespeed-results/
+      - sitespeed-results/
+    reports:
+      performance: performance.json
 ```
 
-The above example will:
+The above example will create a `performance` job in your CI/CD pipeline and will run
+Sitespeed.io against the webpage you defined in `URL` to gather key metrics.
+The [GitLab plugin](https://gitlab.com/gitlab-org/gl-performance) for
+Sitespeed.io is downloaded in order to save the report as a
+[Performance report artifact](https://docs.gitlab.com/ee//ci/yaml/README.html#artifactsreportsperformance)
+that you can later download and analyze.
+Due to implementation limitations we always take the latest Performance artifact available.
 
-1. Create a `performance` job in your CI/CD pipeline and will run
-   Sitespeed.io against the webpage you defined in `URL`.
-1. The [GitLab plugin](https://gitlab.com/gitlab-org/gl-performance) for
-   Sitespeed.io is downloaded in order to export key metrics to JSON. The full
-   HTML Sitespeed.io report will also be saved as an artifact, and if you have
-   [GitLab Pages](../../user/project/pages/index.md) enabled, it can be viewed
-   directly in your browser.
+The full HTML Sitespeed.io report will also be saved as an artifact, and if you have
+[GitLab Pages](../../user/project/pages/index.md) enabled, it can be viewed
+directly in your browser.
 
 For further customization options of Sitespeed.io, including the ability to
 provide a list of URLs to test, please consult
@@ -46,8 +55,8 @@ provide a list of URLs to test, please consult
 
 TIP: **Tip:**
 For [GitLab Premium](https://about.gitlab.com/pricing/) users, key metrics are automatically
-extracted and shown right in the merge request widget. Learn more about
-[Browser Performance Testing](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html).
+extracted and shown right in the merge request widget.
+[Learn more on Browser Performance Testing in merge requests](https://docs.gitlab.com/ee//user/project/merge_requests/browser_performance_testing.html).
 
 ## Performance testing on Review Apps
 
@@ -106,8 +115,40 @@ performance:
     - mv sitespeed-results/data/performance.json performance.json
   artifacts:
     paths:
-      - performance.json
       - sitespeed-results/
+    reports:
+      performance: performance.json
 ```
 
 A complete example can be found in our [Auto DevOps CI YML](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml).
+
+## Previous job definitions
+
+CAUTION: **Caution:**
+Before GitLab 11.5, Performance job and artifact had to be named specifically
+to automatically extract report data and show it in the merge request widget.
+While these old job definitions are still maintained they have been deprecated
+and may be removed in next major release, GitLab 12.0.
+You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
+
+For GitLab 11.4 and earlier, the job should look like:
+
+```yaml
+performance:
+  stage: performance
+  image: docker:git
+  variables:
+    URL: https://example.com
+  services:
+    - docker:stable-dind
+  script:
+    - mkdir gitlab-exporter
+    - wget -O ./gitlab-exporter/index.js https://gitlab.com/gitlab-org/gl-performance/raw/master/index.js
+    - mkdir sitespeed-results
+    - docker run --shm-size=1g --rm -v "$(pwd)":/sitespeed.io sitespeedio/sitespeed.io:6.3.1 --plugins.add ./gitlab-exporter --outputFolder sitespeed-results $URL
+    - mv sitespeed-results/data/performance.json performance.json
+  artifacts:
+    paths:
+      - performance.json
+      - sitespeed-results/
+```
\ No newline at end of file
diff --git a/doc/ci/examples/code_quality.md b/doc/ci/examples/code_quality.md
index 2a7040ecdeb77de99fcb0542e7c56b6bfbf37378..ae000b9d30d5d37db9a4786b69edf78d27246957 100644
--- a/doc/ci/examples/code_quality.md
+++ b/doc/ci/examples/code_quality.md
@@ -1,11 +1,18 @@
 # Analyze your project's Code Quality
 
+CAUTION: **Caution:**
+The job definition shown below is supported on GitLab 11.5 and later versions.
+It also requires the GitLab Runner 11.5 or later.
+For earlier versions, use the [previous job definitions](#previous-job-definitions).
+
 This example shows how to run Code Quality on your code by using GitLab CI/CD
 and Docker.
 
-First, you need GitLab Runner with [docker-in-docker executor][dind].
+First, you need GitLab Runner with
+[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
 
-Once you set up the Runner, add a new job to `.gitlab-ci.yml`, called `code_quality`:
+Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
+generates the expected report:
 
 ```yaml
 code_quality:
@@ -23,27 +30,72 @@ code_quality:
         --volume /var/run/docker.sock:/var/run/docker.sock
         "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
   artifacts:
-    paths: [gl-code-quality-report.json]
+    reports:
+      codequality: gl-code-quality-report.json
 ```
 
 The above example will create a `code_quality` job in your CI/CD pipeline which
-will scan your source code for code quality issues. The report will be saved
-as an artifact that you can later download and analyze.
+will scan your source code for code quality issues. The report will be saved as a
+[Code Quality report artifact](../../ci/yaml/README.md#artifactsreportscodequality)
+that you can later download and analyze.
+Due to implementation limitations we always take the latest Code Quality artifact available.
 
 TIP: **Tip:**
-Starting with [GitLab Starter][ee] 9.3, this information will
-be automatically extracted and shown right in the merge request widget. To do
-so, the CI/CD job must be named `code_quality` and the artifact path must be
-`gl-code-quality-report.json`.
+For [GitLab Starter][ee] users, this information will be automatically
+extracted and shown right in the merge request widget.
 [Learn more on Code Quality in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html).
 
+## Previous job definitions
+
 CAUTION: **Caution:**
-Code Quality was previously using `codeclimate` and `codequality` for job name and
-`codeclimate.json` for the artifact name. While these old names
-are still maintained they have been deprecated with GitLab 11.0 and may be removed
-in next major release, GitLab 12.0. You are advised to update your current `.gitlab-ci.yml`
-configuration to reflect that change.
+Before GitLab 11.5, Code Quality job and artifact had to be named specifically
+to automatically extract report data and show it in the merge request widget.
+While these old job definitions are still maintained they have been deprecated
+and may be removed in next major release, GitLab 12.0.
+You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
+
+For GitLab 11.4 and earlier, the job should look like:
+
+```yaml
+code_quality:
+  image: docker:stable
+  variables:
+    DOCKER_DRIVER: overlay2
+  allow_failure: true
+  services:
+    - docker:stable-dind
+  script:
+    - export SP_VERSION=$(echo "$CI_SERVER_VERSION" | sed 's/^\([0-9]*\)\.\([0-9]*\).*/\1-\2-stable/')
+    - docker run
+        --env SOURCE_CODE="$PWD"
+        --volume "$PWD":/code
+        --volume /var/run/docker.sock:/var/run/docker.sock
+        "registry.gitlab.com/gitlab-org/security-products/codequality:$SP_VERSION" /code
+  artifacts:
+      paths: [gl-code-quality-report.json]
+```
+
+Alternatively the job name could be `codeclimate` or `codequality`
+and the artifact name could be `codeclimate.json`.
+These names have been deprecated with GitLab 11.0
+and may be removed in next major release, GitLab 12.0.
+
+For GitLab 10.3 and earlier, the job should look like:
+
+```yaml
+codequality:
+  image: docker:latest
+  variables:
+    DOCKER_DRIVER: overlay
+  services:
+    - docker:dind
+  script:
+    - docker pull codeclimate/codeclimate:0.69.0
+    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate:0.69.0 init
+    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate:0.69.0 analyze -f json > codeclimate.json || true
+  artifacts:
+    paths: [codeclimate.json]
+```
 
 [cli]: https://github.com/codeclimate/codeclimate
-[dind]: ../docker/using_docker_build.md#use-docker-in-docker-executor
 [ee]: https://about.gitlab.com/pricing/
diff --git a/doc/ci/examples/container_scanning.md b/doc/ci/examples/container_scanning.md
index bc948dc6ea981548885dd814b3ee2a64303b7cfd..68330261910ae9e46199a0152ad47d6c4991b888 100644
--- a/doc/ci/examples/container_scanning.md
+++ b/doc/ci/examples/container_scanning.md
@@ -1,13 +1,20 @@
 # Container Scanning with GitLab CI/CD
 
+CAUTION: **Caution:**
+The job definition shown below is supported on GitLab 11.5 and later versions.
+It also requires the GitLab Runner 11.5 or later.
+For earlier versions, use the [previous job definitions](#previous-job-definitions).
+
 You can check your Docker images (or more precisely the containers) for known
 vulnerabilities by using [Clair](https://github.com/coreos/clair) and
 [clair-scanner](https://github.com/arminc/clair-scanner), two open source tools
 for Vulnerability Static Analysis for containers.
 
-All you need is a GitLab Runner with the Docker executor (the shared Runners on
-GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`,
-called `container_scanning`:
+First, you need GitLab Runner with
+[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
+
+Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
+generates the expected report:
 
 ```yaml
 container_scanning:
@@ -36,32 +43,26 @@ container_scanning:
     - while( ! wget -T 10 -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done
     - ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-container-scanning-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true
   artifacts:
-    paths: [gl-container-scanning-report.json]
+    reports:
+      container_scanning: gl-container-scanning-report.json
 ```
 
 The above example will create a `container_scanning` job in your CI/CD pipeline, pull
 the image from the [Container Registry](../../user/project/container_registry.md)
 (whose name is defined from the two `CI_APPLICATION_` variables) and scan it
-for possible vulnerabilities. The report will be saved as an artifact that you
-can later download and analyze.
+for possible vulnerabilities. The report will be saved as a
+[Container Scanning report artifact](https://docs.gitlab.com/ee//ci/yaml/README.html#artifactsreportscontainer_scanning)
+that you can later download and analyze.
+Due to implementation limitations we always take the latest Container Scanning artifact available.
 
 If you want to whitelist some specific vulnerabilities, you can do so by defining
 them in a [YAML file](https://github.com/arminc/clair-scanner/blob/master/README.md#example-whitelist-yaml-file),
 in our case its named `clair-whitelist.yml`.
 
 TIP: **Tip:**
-Starting with [GitLab Ultimate][ee] 10.4, this information will
-be automatically extracted and shown right in the merge request widget. To do
-so, the CI/CD job must be named `container_scanning` and the artifact path must be
-`gl-container-scanning-report.json`.
-[Learn more on container scanning results shown in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/container_scanning.html).
-
-CAUTION: **Caution:**
-Before GitLab 11.0, Container Scanning was previously using `sast:container` for job name and
-`gl-sast-container-report.json` for the artifact name. While these old names
-are still maintained, they have been deprecated with GitLab 11.0 and may be removed
-in next major release, GitLab 12.0. You are advised to update your current `.gitlab-ci.yml`
-configuration to reflect that change.
+For [GitLab Ultimate][ee] users, this information will
+be automatically extracted and shown right in the merge request widget.
+[Learn more on Container Scanning in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/container_scanning.html).
 
 CAUTION: **Caution:**
 Starting with GitLab 11.5, Container Scanning feature is licensed under the name `container_scanning`.
@@ -69,4 +70,50 @@ While the old name `sast_container` is still maintained, it has been deprecated
 may be removed in next major release, GitLab 12.0. You are advised to update your current `.gitlab-ci.yml`
 configuration to reflect that change if you are using the `$GITLAB_FEATURES` environment variable.
 
+## Previous job definitions
+
+CAUTION: **Caution:**
+Before GitLab 11.5, Container Scanning job and artifact had to be named specifically
+to automatically extract report data and show it in the merge request widget.
+While these old job definitions are still maintained they have been deprecated
+and may be removed in next major release, GitLab 12.0.
+You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
+
+For GitLab 11.4 and earlier, the job should look like:
+
+```yaml
+container_scanning:
+  image: docker:stable
+  variables:
+    DOCKER_DRIVER: overlay2
+    ## Define two new variables based on GitLab's CI/CD predefined variables
+    ## https://docs.gitlab.com/ee/ci/variables/#predefined-variables-environment-variables
+    CI_APPLICATION_REPOSITORY: $CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG
+    CI_APPLICATION_TAG: $CI_COMMIT_SHA
+  allow_failure: true
+  services:
+    - docker:stable-dind
+  script:
+    - docker run -d --name db arminc/clair-db:latest
+    - docker run -p 6060:6060 --link db:postgres -d --name clair --restart on-failure arminc/clair-local-scan:v2.0.1
+    - apk add -U wget ca-certificates
+    - docker pull ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG}
+    - wget https://github.com/arminc/clair-scanner/releases/download/v8/clair-scanner_linux_amd64
+    - mv clair-scanner_linux_amd64 clair-scanner
+    - chmod +x clair-scanner
+    - touch clair-whitelist.yml
+    - while( ! wget -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; done
+    - retries=0
+    - echo "Waiting for clair daemon to start"
+    - while( ! wget -T 10 -q -O /dev/null http://docker:6060/v1/namespaces ) ; do sleep 1 ; echo -n "." ; if [ $retries -eq 10 ] ; then echo " Timeout, aborting." ; exit 1 ; fi ; retries=$(($retries+1)) ; done
+    - ./clair-scanner -c http://docker:6060 --ip $(hostname -i) -r gl-container-scanning-report.json -l clair.log -w clair-whitelist.yml ${CI_APPLICATION_REPOSITORY}:${CI_APPLICATION_TAG} || true
+  artifacts:
+    paths: [gl-container-scanning-report.json]
+```
+
+Alternatively the job name could be `sast:container`
+and the artifact name could be `gl-sast-container-report.json`.
+These names have been deprecated with GitLab 11.0
+and may be removed in next major release, GitLab 12.0.
+
 [ee]: https://about.gitlab.com/pricing/
diff --git a/doc/ci/examples/dast.md b/doc/ci/examples/dast.md
index ff20f0b3b5e3170b2355a0c3099da20a14b24d49..0ca89eb67004b41852efeedf4c69be1855e062a7 100644
--- a/doc/ci/examples/dast.md
+++ b/doc/ci/examples/dast.md
@@ -1,16 +1,26 @@
 # Dynamic Application Security Testing with GitLab CI/CD
 
+CAUTION: **Caution:**
+The job definition shown below is supported on GitLab 11.5 and later versions.
+It also requires the GitLab Runner 11.5 or later.
+For earlier versions, use the [previous job definitions](#previous-job-definitions).
+
 [Dynamic Application Security Testing (DAST)](https://en.wikipedia.org/wiki/Dynamic_program_analysis)
 is using the popular open source tool [OWASP ZAProxy](https://github.com/zaproxy/zaproxy)
 to perform an analysis on your running web application.
+Since it is based on [ZAP Baseline](https://github.com/zaproxy/zaproxy/wiki/ZAP-Baseline-Scan)
+DAST will perform passive scanning only;
+it will not actively attack your application.
 
 It can be very useful combined with [Review Apps](../review_apps/index.md).
 
 ## Example
 
-All you need is a GitLab Runner with the Docker executor (the shared Runners on
-GitLab.com will work fine). You can then add a new job to `.gitlab-ci.yml`,
-called `dast`:
+First, you need GitLab Runner with
+[docker-in-docker executor](../docker/using_docker_build.md#use-docker-in-docker-executor).
+
+Once you set up the Runner, add a new job to `.gitlab-ci.yml` that
+generates the expected report:
 
 ```yaml
 dast:
@@ -23,13 +33,16 @@ dast:
     - /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
     - cp /zap/wrk/gl-dast-report.json .
   artifacts:
-    paths: [gl-dast-report.json]
+    reports:
+      dast: gl-dast-report.json
 ```
 
 The above example will create a `dast` job in your CI/CD pipeline which will run
 the tests on the URL defined in the `website` variable (change it to use your
-own) and finally write the results in the `gl-dast-report.json` file. You can
-then download and analyze the report artifact in JSON format.
+own) and scan it for possible vulnerabilities. The report will be saved as a
+[DAST report artifact](https://docs.gitlab.com/ee//ci/yaml/README.html#artifactsreportsdast)
+that you can later download and analyze.
+Due to implementation limitations we always take the latest DAST artifact available.
 
 It's also possible to authenticate the user before performing DAST checks:
 
@@ -39,25 +52,51 @@ dast:
   variables:
     website: "https://example.com"
     login_url: "https://example.com/sign-in"
+    username: "john.doe@example.com"
+    password: "john-doe-password"
   allow_failure: true
   script:
     - mkdir /zap/wrk/
     - /zap/zap-baseline.py -J gl-dast-report.json -t $website
         --auth-url $login_url
-        --auth-username "john.doe@example.com"
-        --auth-password "john-doe-password" || true
+        --auth-username $username
+        --auth-password $password || true
     - cp /zap/wrk/gl-dast-report.json .
   artifacts:
-    paths: [gl-dast-report.json]
+    reports:
+      dast: gl-dast-report.json
 ```
 See [zaproxy documentation](https://gitlab.com/gitlab-org/security-products/zaproxy)
 to learn more about authentication settings.
 
 TIP: **Tip:**
-Starting with [GitLab Ultimate][ee] 10.4, this information will
-be automatically extracted and shown right in the merge request widget. To do
-so, the CI job must be named `dast` and the artifact path must be
-`gl-dast-report.json`.
-[Learn more about DAST results shown in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html).
+For [GitLab Ultimate][ee] users, this information will
+be automatically extracted and shown right in the merge request widget.
+[Learn more on DAST in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html).
+
+## Previous job definitions
+
+CAUTION: **Caution:**
+Before GitLab 11.5, DAST job and artifact had to be named specifically
+to automatically extract report data and show it in the merge request widget.
+While these old job definitions are still maintained they have been deprecated
+and may be removed in next major release, GitLab 12.0.
+You are advised to update your current `.gitlab-ci.yml` configuration to reflect that change.
+
+For GitLab 11.4 and earlier, the job should look like:
+
+```yaml
+dast:
+  image: registry.gitlab.com/gitlab-org/security-products/zaproxy
+  variables:
+    website: "https://example.com"
+  allow_failure: true
+  script:
+    - mkdir /zap/wrk/
+    - /zap/zap-baseline.py -J gl-dast-report.json -t $website || true
+    - cp /zap/wrk/gl-dast-report.json .
+  artifacts:
+    paths: [gl-dast-report.json]
+```
 
 [ee]: https://about.gitlab.com/pricing/
diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md
index 55ff131efaac4c250b95d12a0174fcaf724bb766..36358515b841bacf3d0e2eda01d27a20f2ebc51e 100644
--- a/doc/ci/examples/deployment/composer-npm-deploy.md
+++ b/doc/ci/examples/deployment/composer-npm-deploy.md
@@ -33,9 +33,9 @@ before_script:
 In this particular case, the `npm deploy` script is a Gulp script that does the following:
 
 1. Compile CSS & JS
-2. Create sprites
-3. Copy various assets (images, fonts) around
-4. Replace some strings
+1. Create sprites
+1. Copy various assets (images, fonts) around
+1. Replace some strings
 
 All these operations will put all files into a `build` folder, which is ready to be deployed to a live server.
 
@@ -62,10 +62,10 @@ before_script:
 
 In order, this means that:
 
-1. We check if the `ssh-agent` is available and we install it if it's not;
-2. We create the `~/.ssh` folder;
-3. We make sure we're running bash;
-4. We disable host checking (we don't ask for user accept when we first connect to a server; and since every job will equal a first connect, we kind of need this)
+1. We check if the `ssh-agent` is available and we install it if it's not.
+1. We create the `~/.ssh` folder.
+1. We make sure we're running bash.
+1. We disable host checking (we don't ask for user accept when we first connect to a server and since every job will equal a first connect, we kind of need this).
 
 And this is basically all you need in the `before_script` section.
 
@@ -91,11 +91,11 @@ stage_deploy:
 Here's the breakdown:
 
 1. `only:dev` means that this build will run only when something is pushed to the `dev` branch. You can remove this block completely and have everything be ran on every push (but probably this is something you don't want)
-2. `ssh-add ...` we will add that private key you added on the web UI to the docker container
-3. We will connect via `ssh` and create a new `_tmp` folder
-4. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
-5. We will connect again to `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
-6. We connect to ssh and remove the `_old` folder
+1. `ssh-add ...` we will add that private key you added on the web UI to the docker container
+1. We will connect via `ssh` and create a new `_tmp` folder
+1. We will connect via `scp` and upload the `build` folder (which was generated by a `npm` script) to our previously created `_tmp` folder
+1. We will connect again to `ssh` and move the `live` folder to an `_old` folder, then move `_tmp` to `live`.
+1. We connect to ssh and remove the `_old` folder
 
 What's the deal with the artifacts? We just tell GitLab CI to keep the `build` directory (later on, you can download that as needed).
 
diff --git a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
index 087b317ab73d8e028db22ceefdaa96b6de556553..ec0b5aaed09c1a2439e8a7c2568ea5b9fb4798dd 100644
--- a/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
+++ b/doc/ci/examples/test-and-deploy-python-application-to-heroku.md
@@ -40,15 +40,17 @@ production:
 ```
 
 This project has three jobs:
-1. `test` - used to test Django application,
-2. `staging` - used to automatically deploy staging environment every push to `master` branch
-3. `production` - used to automatically deploy production environment for every created tag
+
+- `test` - used to test Django application,
+- `staging` - used to automatically deploy staging environment every push to `master` branch
+- `production` - used to automatically deploy production environment for every created tag
 
 ## Store API keys
 
 You'll need to create two variables in `Settings > CI/CD > Variables` on your GitLab project settings:
-1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
-2. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
+
+- `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app.
+- `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
 
 Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/account).
 
diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
index 7f9ab1f3a5e04e6d0497309ca62b0497c0be605a..33a353f17f5aedea54bb269859e3b78402a049a2 100644
--- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
+++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md
@@ -36,16 +36,17 @@ production:
 ```
 
 This project has three jobs:
-1. `test` - used to test Rails application,
-2. `staging` - used to automatically deploy staging environment every push to `master` branch
-3. `production` - used to automatically deploy production environment for every created tag
+
+- `test` - used to test Rails application.
+- `staging` - used to automatically deploy staging environment every push to `master` branch.
+- `production` - used to automatically deploy production environment for every created tag.
 
 ## Store API keys
 
 You'll need to create two variables in your project's **Settings > CI/CD > Variables**:
 
-1. `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app,
-2. `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
+- `HEROKU_STAGING_API_KEY` - Heroku API key used to deploy staging app.
+- `HEROKU_PRODUCTION_API_KEY` - Heroku API key used to deploy production app.
 
 Find your Heroku API key in [Manage Account](https://dashboard.heroku.com/account).
 
diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md
index 636117536a2c9af5ea867462f435577e022ce719..bdc593493ea54e417c900b315a46f7dbca9bcda3 100644
--- a/doc/ci/quick_start/README.md
+++ b/doc/ci/quick_start/README.md
@@ -168,7 +168,7 @@ can be found at <https://docs.gitlab.com/runner/>.
 In order to have a functional Runner you need to follow two steps:
 
 1. [Install it][runner-install]
-2. [Configure it](../runners/README.md#registering-a-specific-runner)
+1. [Configure it](../runners/README.md#registering-a-specific-runner)
 
 Follow the links above to set up your own Runner or use a Shared Runner as
 described in the next section.
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
index 2a179bfbbf0969e9a3054ec97419c94a4970a32a..9c9ea651678267ef2fb72f4d4fa037972d76a210 100644
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
@@ -138,9 +138,9 @@ project without requiring your authorization, so use it with caution.
 An admin can enable/disable a specific Runner for projects:
 
 1. Navigate to **Admin > Runners**
-2. Find the Runner you wish to enable/disable
-3. Click edit on the Runner
-4. Click **Enable** or **Disable** on the project
+1. Find the Runner you wish to enable/disable
+1. Click edit on the Runner
+1. Click **Enable** or **Disable** on the project
 
 ## Protected Runners
 
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 5deeb2b01333d2dd73e7caa78710f2ce59cba5ed..aab5f268ef9ea8e92cead97eba00d3165c9f03b2 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -103,7 +103,7 @@ rspec:
       - $RSPEC
 ```
 
-In the example above, the `rspec` job inherits from the `.tests` template job. 
+In the example above, the `rspec` job inherits from the `.tests` template job.
 GitLab will perform a reverse deep merge based on the keys. GitLab will:
 
 - Merge the `rspec` contents into `.tests` recursively.
@@ -1337,6 +1337,81 @@ concatenated into a single file. Use a filename pattern (`junit: rspec-*.xml`),
 an array of filenames (`junit: [rspec-1.xml, rspec-2.xml, rspec-3.xml]`), or a
 combination thereof (`junit: [rspec.xml, test-results/TEST-*.xml]`).
 
+#### `artifacts:reports:codequality` **[STARTER]**
+
+> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
+
+The `codequality` report collects [CodeQuality issues](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html)
+as artifacts.
+
+The collected Code Quality report will be uploaded to GitLab as an artifact and will
+be automatically shown in merge requests.
+
+#### `artifacts:reports:sast` **[ULTIMATE]**
+
+> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
+
+The `sast` report collects [SAST vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/sast.html)
+as artifacts.
+
+The collected SAST report will be uploaded to GitLab as an artifact and will
+be automatically shown in merge requests, pipeline view and provide data for security
+dashboards.
+
+#### `artifacts:reports:dependency_scanning` **[ULTIMATE]**
+
+> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
+
+The `dependency_scanning` report collects [Dependency Scanning vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/dependency_scanning.html)
+as artifacts.
+
+The collected Dependency Scanning report will be uploaded to GitLab as an artifact and will
+be automatically shown in merge requests, pipeline view and provide data for security
+dashboards.
+
+#### `artifacts:reports:container_scanning` **[ULTIMATE]**
+
+> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
+
+The `container_scanning` report collects [Container Scanning vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/container_scanning.html)
+as artifacts.
+
+The collected Container Scanning report will be uploaded to GitLab as an artifact and will
+be automatically shown in merge requests, pipeline view and provide data for security
+dashboards.
+
+#### `artifacts:reports:dast` **[ULTIMATE]**
+
+> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
+
+The `dast` report collects [DAST vulnerabilities](https://docs.gitlab.com/ee/user/project/merge_requests/dast.html)
+as artifacts.
+
+The collected DAST report will be uploaded to GitLab as an artifact and will
+be automatically shown in merge requests, pipeline view and provide data for security
+dashboards.
+
+#### `artifacts:reports:license_management` **[ULTIMATE]**
+
+> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
+
+The `license_management` report collects [Licenses](https://docs.gitlab.com/ee/user/project/merge_requests/license_management.html)
+as artifacts.
+
+The collected License Management report will be uploaded to GitLab as an artifact and will
+be automatically shown in merge requests, pipeline view and provide data for security
+dashboards.
+
+#### `artifacts:reports:performance` **[PREMIUM]**
+
+> Introduced in GitLab 11.5. Requires GitLab Runner 11.5 and above.
+
+The `performance` report collects [Performance metrics](https://docs.gitlab.com/ee//user/project/merge_requests/browser_performance_testing.html)
+as artifacts.
+
+The collected Performance report will be uploaded to GitLab as an artifact and will
+be automatically shown in merge requests.
+
 ## `dependencies`
 
 > Introduced in GitLab 8.6 and GitLab Runner v1.1.1.
diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md
index ea6f14da3b93d42dbfde0f2f52aaecb36ae1aed6..d1d2b8c4907a7c190133365f416216522f03558c 100644
--- a/doc/development/adding_database_indexes.md
+++ b/doc/development/adding_database_indexes.md
@@ -28,9 +28,9 @@ to filter data by. Instead one should ask themselves the following questions:
 
 1. Can I write my query in such a way that it re-uses as many existing indexes
    as possible?
-2. Is the data going to be large enough that using an index will actually be
+1. Is the data going to be large enough that using an index will actually be
    faster than just iterating over the rows in the table?
-3. Is the overhead of maintaining the index worth the reduction in query
+1. Is the overhead of maintaining the index worth the reduction in query
    timings?
 
 We'll explore every question in detail below.
@@ -62,7 +62,7 @@ In short:
 
 1. Try to write your query in such a way that it re-uses as many existing
    indexes as possible.
-2. Run the query using `EXPLAIN ANALYZE` and study the output to find the most
+1. Run the query using `EXPLAIN ANALYZE` and study the output to find the most
    ideal query.
 
 ## Data Size
diff --git a/doc/development/build_test_package.md b/doc/development/build_test_package.md
index 439d228baefb46a1e9ec8d94453d04f535321110..c5f6adfeaeb53e1bcc64744139c484d49d0f3f52 100644
--- a/doc/development/build_test_package.md
+++ b/doc/development/build_test_package.md
@@ -4,12 +4,13 @@ While developing a new feature or modifying an existing one, it is helpful if an
 installable package (or a docker image) containing those changes is available
 for testing. For this very purpose, a manual job is provided in the GitLab CI/CD
 pipeline that can be used to trigger a pipeline in the omnibus-gitlab repository
-that will create
-1. A deb package for Ubuntu 16.04, available as a build artifact, and
-2. A docker image, which is pushed to [Omnibus GitLab's container 
-registry](https://gitlab.com/gitlab-org/omnibus-gitlab/container_registry)
-(images titled `gitlab-ce` and `gitlab-ee` respectively and image tag is the
-commit which triggered the pipeline).
+that will create:
+
+- A deb package for Ubuntu 16.04, available as a build artifact, and
+- A docker image, which is pushed to [Omnibus GitLab's container
+  registry](https://gitlab.com/gitlab-org/omnibus-gitlab/container_registry)
+  (images titled `gitlab-ce` and `gitlab-ee` respectively and image tag is the
+  commit which triggered the pipeline).
 
 When you push a commit to either the gitlab-ce or gitlab-ee project, the
 pipeline for that commit will have a `build-package` manual action you can
diff --git a/doc/development/code_review.md b/doc/development/code_review.md
index 96f3861f8d788d9146190a13f8ae141085866679..52710e54e86dae7efe94ecd9fcb9e3051bc9b530 100644
--- a/doc/development/code_review.md
+++ b/doc/development/code_review.md
@@ -9,11 +9,11 @@ code is effective, understandable, and maintainable.
 
 ## Getting your merge request reviewed, approved, and merged
 
-You are strongly encouraged to get your code **reviewed** by a 
+You are strongly encouraged to get your code **reviewed** by a
 [reviewer](https://about.gitlab.com/handbook/engineering/#reviewer) as soon as
 there is any code to review, to get a second opinion on the chosen solution and
 implementation, and an extra pair of eyes looking for bugs, logic problems, or
-uncovered edge cases. The reviewer can be from a different team, but it is 
+uncovered edge cases. The reviewer can be from a different team, but it is
 recommended to pick someone who knows the domain well. You can read more about the
 importance of involving reviewer(s) in the section on the responsibility of the author below.
 
@@ -23,7 +23,7 @@ one of the [Merge request coaches][team].
 Depending on the areas your merge request touches, it must be **approved** by one
 or more [maintainers](https://about.gitlab.com/handbook/engineering/#maintainer):
 
-For approvals, we use the approval functionality found in the merge request 
+For approvals, we use the approval functionality found in the merge request
 widget. Reviewers can add their approval by [approving additionally](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#adding-or-removing-an-approval).
 
    1. If your merge request includes backend changes [^1], it must be
@@ -42,43 +42,43 @@ widget. Reviewers can add their approval by [approving additionally](https://doc
 Getting your merge request **merged** also requires a maintainer. If it requires
 more than one approval, the last maintainer to review and approve it will also merge it.
 
-As described in the section on the responsibility of the maintainer below, you 
-are recommended to get your merge request approved and merged by maintainer(s) 
+As described in the section on the responsibility of the maintainer below, you
+are recommended to get your merge request approved and merged by maintainer(s)
 from other teams than your own.
 
 ### The responsibility of the merge request author
 
 The responsibility to find the best solution and implement it lies with the
-merge request author. 
+merge request author.
 
-Before assigning a merge request to a maintainer for approval and merge, they 
-should be confident that it actually solves the problem it was meant to solve, 
-that it does so in the most appropriate way, that it satisfies all requirements, 
-and that there are no remaining bugs, logical problems, or uncovered edge cases. 
-The merge request should also have a completed task list in its description and 
+Before assigning a merge request to a maintainer for approval and merge, they
+should be confident that it actually solves the problem it was meant to solve,
+that it does so in the most appropriate way, that it satisfies all requirements,
+and that there are no remaining bugs, logical problems, or uncovered edge cases.
+The merge request should also have a completed task list in its description and
 a passing CI pipeline to avoid unnecessary back and forth.
 
 To reach the required level of confidence in their solution, an author is expected
-to involve other people in the investigation and implementation processes as 
+to involve other people in the investigation and implementation processes as
 appropriate.
 
-They are encouraged to reach out to domain experts to discuss different solutions 
-or get an implementation reviewed, to product managers and UX designers to clear 
-up confusion or verify that the end result matches what they had in mind, to 
+They are encouraged to reach out to domain experts to discuss different solutions
+or get an implementation reviewed, to product managers and UX designers to clear
+up confusion or verify that the end result matches what they had in mind, to
 database specialists to get input on the data model or specific queries, or to
 any other developer to get an in-depth review of the solution.
 
 If an author is unsure if a merge request needs a domain expert's opinion, that's
-usually a pretty good sign that it does, since without it the required level of 
+usually a pretty good sign that it does, since without it the required level of
 confidence in their solution will not have been reached.
 
 ### The responsibility of the maintainer
 
 Maintainers are responsible for the overall health, quality, and consistency of
-the GitLab codebase, across domains and product areas. 
+the GitLab codebase, across domains and product areas.
 
-Consequently, their reviews will focus primarily on things like overall 
-architecture, code organization, separation of concerns, tests, DRYness, 
+Consequently, their reviews will focus primarily on things like overall
+architecture, code organization, separation of concerns, tests, DRYness,
 consistency, and readability.
 
 Since a maintainer's job only depends on their knowledge of the overall GitLab
@@ -87,12 +87,12 @@ merge requests from any team and in any product area.
 
 In fact, authors are recommended to get their merge requests merged by maintainers
 from other teams than their own, to ensure that all code across GitLab is consistent
-and can be easily understood by all contributors, from both inside and outside the 
+and can be easily understood by all contributors, from both inside and outside the
 company, without requiring team-specific expertise.
 
 Maintainers will do their best to also review the specifics of the chosen solution
 before merging, but as they are not necessarily domain experts, they may be poorly
-placed to do so without an unreasonable investment of time. In those cases, they 
+placed to do so without an unreasonable investment of time. In those cases, they
 will defer to the judgment of the author and earlier reviewers and involved domain
 experts, in favor of focusing on their primary responsibilities.
 
@@ -100,7 +100,7 @@ If a developer who happens to also be a maintainer was involved in a merge reque
 as a domain expert and/or reviewer, it is recommended that they are not also picked
 as the maintainer to ultimately approve and merge it.
 
-Maintainers should check before merging if the merge request is approved by the 
+Maintainers should check before merging if the merge request is approved by the
 required approvers.
 
 ## Best practices
@@ -230,41 +230,41 @@ Enterprise Edition instance. This has some implications:
 1. **Query changes** should be tested to ensure that they don't result in worse
    performance at the scale of GitLab.com:
    1. Generating large quantities of data locally can help.
-   2. Asking for query plans from GitLab.com is the most reliable way to validate
+   1. Asking for query plans from GitLab.com is the most reliable way to validate
       these.
-2. **Database migrations** must be:
+1. **Database migrations** must be:
    1. Reversible.
-   2. Performant at the scale of GitLab.com - ask a maintainer to test the
+   1. Performant at the scale of GitLab.com - ask a maintainer to test the
       migration on the staging environment if you aren't sure.
-   3. Categorised correctly:
+   1. Categorised correctly:
       - Regular migrations run before the new code is running on the instance.
       - [Post-deployment migrations](post_deployment_migrations.md) run _after_
         the new code is deployed, when the instance is configured to do that.
       - [Background migrations](background_migrations.md) run in Sidekiq, and
         should only be done for migrations that would take an extreme amount of
         time at GitLab.com scale.
-3. **Sidekiq workers**
+1. **Sidekiq workers**
    [cannot change in a backwards-incompatible way](sidekiq_style_guide.md#removing-or-renaming-queues):
    1. Sidekiq queues are not drained before a deploy happens, so there will be
       workers in the queue from the previous version of GitLab.
-   2. If you need to change a method signature, try to do so across two releases,
+   1. If you need to change a method signature, try to do so across two releases,
       and accept both the old and new arguments in the first of those.
-   3. Similarly, if you need to remove a worker, stop it from being scheduled in
+   1. Similarly, if you need to remove a worker, stop it from being scheduled in
       one release, then remove it in the next. This will allow existing jobs to
       execute.
-   4. Don't forget, not every instance will upgrade to every intermediate version
+   1. Don't forget, not every instance will upgrade to every intermediate version
       (some people may go from X.1.0 to X.10.0, or even try bigger upgrades!), so
       try to be liberal in accepting the old format if it is cheap to do so.
-4. **Cached values** may persist across releases. If you are changing the type a
+1. **Cached values** may persist across releases. If you are changing the type a
    cached value returns (say, from a string or nil to an array), change the
    cache key at the same time.
-5. **Settings** should be added as a
+1. **Settings** should be added as a
    [last resort](https://about.gitlab.com/handbook/product/#convention-over-configuration).
    If you're adding a new setting in `gitlab.yml`:
    1. Try to avoid that, and add to `ApplicationSetting` instead.
-   2. Ensure that it is also
+   1. Ensure that it is also
       [added to Omnibus](https://docs.gitlab.com/omnibus/settings/gitlab.yml.html#adding-a-new-setting-to-gitlab-yml).
-6. **Filesystem access** can be slow, so try to avoid
+1. **Filesystem access** can be slow, so try to avoid
    [shared files](shared_files.md) when an alternative solution is available.
 
 ### Credits
diff --git a/doc/development/diffs.md b/doc/development/diffs.md
index 4adae5dabe24ba8a8d188a6373d36e890a2ee6ef..43fc125c21d2f1fdbe4a73b3b1a696b6739d8f16 100644
--- a/doc/development/diffs.md
+++ b/doc/development/diffs.md
@@ -17,20 +17,20 @@ The diffs fetching process _limits_ single file diff sizes and the overall size
 then persisted on `merge_request_diff_files` table.
 
 Even though diffs larger than 10% of the value of `ApplicationSettings#diff_max_patch_bytes` are collapsed,
-we still keep them on Postgres. However, diff files larger than defined _safety limits_ 
+we still keep them on Postgres. However, diff files larger than defined _safety limits_
 (see the [Diff limits section](#diff-limits)) are _not_ persisted in the database.
 
 In order to present diffs information on the Merge Request diffs page, we:
 
 1. Fetch all diff files from database `merge_request_diff_files`
-2. Fetch the _old_ and _new_ file blobs in batch to:
-   1. Highlight old and new file content
-   2. Know which viewer it should use for each file (text, image, deleted, etc)
-   3. Know if the file content changed
-   4. Know if it was stored externally
-   5. Know if it had storage errors
-3. If the diff file is cacheable (text-based), it's cached on Redis
-using `Gitlab::Diff::FileCollection::MergeRequestDiff`
+1. Fetch the _old_ and _new_ file blobs in batch to:
+   - Highlight old and new file content
+   - Know which viewer it should use for each file (text, image, deleted, etc)
+   - Know if the file content changed
+   - Know if it was stored externally
+   - Know if it had storage errors
+1. If the diff file is cacheable (text-based), it's cached on Redis
+   using `Gitlab::Diff::FileCollection::MergeRequestDiff`
 
 ### Note diffs
 
@@ -39,9 +39,9 @@ on `NoteDiffFile` (which is associated with the actual `DiffNote`). So instead
 of hitting the repository every time we need the diff of the file, we:
 
 1. Check whether we have the `NoteDiffFile#diff` persisted and use it
-2. Otherwise, if it's a current MR revision, use the persisted
-`MergeRequestDiffFile#diff`
-3. In the last scenario, go the the repository and fetch the diff
+1. Otherwise, if it's a current MR revision, use the persisted
+   `MergeRequestDiffFile#diff`
+1. In the last scenario, go the repository and fetch the diff
 
 ## Diff limits
 
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index b6f053ff0e9e379021579d8fb5724695a5dcbea3..9aea03139eeeb4b288c6defc3b453ffa148a35cb 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -119,10 +119,20 @@ This also applies to views.
 
 ### EE features based on CE features
 
-For features that build on existing CE features, write a module in the
-`EE` namespace and `prepend` it in the CE class. This makes conflicts
-less likely to happen during CE to EE merges because only one line is
-added to the CE class - the `prepend` line.
+For features that build on existing CE features, write a module in the `EE`
+namespace and `prepend` it in the CE class, on the last line of the file that
+the class resides in. This makes conflicts less likely to happen during CE to EE
+merges because only one line is added to the CE class - the `prepend` line. For
+example, to prepend a module into the `User` class you would use the following
+approach:
+
+```ruby
+class User < ActiveRecord::Base
+  # ... lots of code here ...
+end
+
+User.prepend(EE::User)
+```
 
 Since the module would require an `EE` namespace, the file should also be
 put in an `ee/` sub-directory. For example, we want to extend the user model
@@ -231,7 +241,6 @@ the existing file:
 
 ```ruby
 class ApplicationController < ActionController::Base
-  prepend EE::ApplicationController
   # ...
 
   def after_sign_out_path_for(resource)
@@ -240,6 +249,8 @@ class ApplicationController < ActionController::Base
 
   # ...
 end
+
+ApplicationController.prepend(EE::ApplicationController)
 ```
 
 And create a new file in the `ee/` sub-directory with the altered
@@ -533,8 +544,6 @@ module API
       end
     end
 
-    prepend EE::API::MergeRequests
-
     params :optional_params do
       # CE specific params go here...
 
@@ -542,6 +551,8 @@ module API
     end
   end
 end
+
+API::MergeRequests.prepend(EE::API::MergeRequests)
 ```
 
 And then we could override it in EE module:
@@ -582,10 +593,10 @@ module API
         authorize_read_builds!
       end
     end
-
-    prepend EE::API::JobArtifacts
   end
 end
+
+API::JobArtifacts.prepend(EE::API::JobArtifacts)
 ```
 
 And then we can follow regular object-oriented practices to override it:
@@ -626,8 +637,6 @@ module API
       end
     end
 
-    prepend EE::API::MergeRequests
-
     put ':id/merge_requests/:merge_request_iid/merge' do
       merge_request = find_project_merge_request(params[:merge_request_iid])
 
@@ -639,6 +648,8 @@ module API
     end
   end
 end
+
+API::MergeRequests.prepend(EE::API::MergeRequests)
 ```
 
 Note that `update_merge_request_ee` doesn't do anything in CE, but
@@ -676,27 +687,37 @@ or not we really need to extend it from EE. For now we're not using it much.
 
 Sometimes we need to use different arguments for a particular API route, and we
 can't easily extend it with an EE module because Grape has different context in
-different blocks. In order to overcome this, we could use class methods from the
-API class.
+different blocks. In order to overcome this, we need to move the data to a class
+method that resides in a separate module or class. This allows us to extend that
+module or class before its data is used, without having to place a `prepend` in
+the middle of CE code.
 
 For example, in one place we need to pass an extra argument to
 `at_least_one_of` so that the API could consider an EE-only argument as the
-least argument. This is not quite beautiful but it's working:
+least argument. We would approach this as follows:
 
 ```ruby
+# api/merge_requests/parameters.rb
 module API
   class MergeRequests < Grape::API
-    def self.update_params_at_least_one_of
-      %i[
-        assignee_id
-        description
-      ]
+    module Parameters
+      def self.update_params_at_least_one_of
+        %i[
+          assignee_id
+          description
+        ]
+      end
     end
+  end
+end
 
-    prepend EE::API::MergeRequests
+API::MergeRequests::Parameters.prepend(EE::API::MergeRequests::Parameters)
 
+# api/merge_requests.rb
+module API
+  class MergeRequests < Grape::API
     params do
-      at_least_one_of(*::API::MergeRequests.update_params_at_least_one_of)
+      at_least_one_of(*Parameters.update_params_at_least_one_of)
     end
   end
 end
@@ -708,16 +729,18 @@ And then we could easily extend that argument in the EE class method:
 module EE
   module API
     module MergeRequests
-      extend ActiveSupport::Concern
+      module Parameters
+        extend ActiveSupport::Concern
 
-      class_methods do
-        extend ::Gitlab::Utils::Override
+        class_methods do
+          extend ::Gitlab::Utils::Override
 
-        override :update_params_at_least_one_of
-        def update_params_at_least_one_of
-          super.push(*%i[
-            squash
-          ])
+          override :update_params_at_least_one_of
+          def update_params_at_least_one_of
+            super.push(*%i[
+              squash
+            ])
+          end
         end
       end
     end
@@ -728,6 +751,78 @@ end
 It could be annoying if we need this for a lot of routes, but it might be the
 simplest solution right now.
 
+This approach can also be used when models define validations that depend on
+class methods. For example:
+
+```ruby
+# app/models/identity.rb
+class Identity < ActiveRecord::Base
+  def self.uniqueness_scope
+    [:provider]
+  end
+
+  prepend EE::Identity
+
+  validates :extern_uid,
+    allow_blank: true,
+    uniqueness: { scope: uniqueness_scope, case_sensitive: false }
+end
+
+# ee/app/models/ee/identity.rb
+module EE
+  module Identity
+    extend ActiveSupport::Concern
+
+    class_methods do
+      extend ::Gitlab::Utils::Override
+
+      def uniqueness_scope
+        [*super, :saml_provider_id]
+      end
+    end
+  end
+end
+```
+
+Instead of taking this approach, we would refactor our code into the following:
+
+```ruby
+# ee/app/models/ee/identity/uniqueness_scopes.rb
+module EE
+  module Identity
+    module UniquenessScopes
+      extend ActiveSupport::Concern
+
+      class_methods do
+        extend ::Gitlab::Utils::Override
+
+        def uniqueness_scope
+          [*super, :saml_provider_id]
+        end
+      end
+    end
+  end
+end
+
+# app/models/identity/uniqueness_scopes.rb
+class Identity < ActiveRecord::Base
+  module UniquenessScopes
+    def self.uniqueness_scope
+      [:provider]
+    end
+  end
+end
+
+Identity::UniquenessScopes.prepend(EE::Identity::UniquenessScopes)
+
+# app/models/identity.rb
+class Identity < ActiveRecord::Base
+  validates :extern_uid,
+    allow_blank: true,
+    uniqueness: { scope: Identity::UniquenessScopes.scopes, case_sensitive: false }
+end
+```
+
 ### Code in `spec/`
 
 When you're testing EE-only features, avoid adding examples to the
diff --git a/doc/development/fe_guide/style_guide_scss.md b/doc/development/fe_guide/style_guide_scss.md
index 48eb6d0a7d608e92c14b98a55b1780f377e56ac0..b09243598d5be2774be9877c4d1096ac96f32e49 100644
--- a/doc/development/fe_guide/style_guide_scss.md
+++ b/doc/development/fe_guide/style_guide_scss.md
@@ -183,9 +183,11 @@ Don't use ID selectors in CSS.
 ```
 
 ### Variables
+
 Before adding a new variable for a color or a size, guarantee:
-1. There isn't already one
-2. There isn't a similar one we can use instead.
+
+- There isn't already one
+- There isn't a similar one we can use instead.
 
 ## Linting
 
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index f6cbd11042c44258c0a772d5fd0a31a8e3f3867e..ccfd465531abd01fa324c09061f07d2b9812c339 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -221,6 +221,14 @@ const vm = mountComponent(Component, data);
 The main return value of a Vue component is the rendered output. In order to test the component we
 need to test the rendered output. [Vue][vue-test] guide's to unit test show us exactly that:
 
+## Vue.js Expert Role
+One should apply to be a Vue.js expert by opening an MR when the Merge Request's they create and review show:
+- Deep understanding of Vue and Vuex reactivy
+- Vue and Vuex code are structured according to both official and our guidelines
+- Full understanding of testing a Vue and Vuex application
+- Vuex code follows the [documented pattern](./vuex.md#actions-pattern-request-and-receive-namespaces)
+- Knowledge about the existing Vue and Vuex applications and existing reusable components
+
 
 [vue-docs]: http://vuejs.org/guide/index.html
 [issue-boards]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/boards
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
index f582f5da32347acbb71e3bd06ab4dac60ce38188..0f57835fb87d086091afa7cd412e5cc90ca4f9cc 100644
--- a/doc/development/fe_guide/vuex.md
+++ b/doc/development/fe_guide/vuex.md
@@ -114,19 +114,21 @@ When a request is made we often want to show a loading state to the user.
 
 Instead of creating an action to toggle the loading state and dispatch it in the component,
 create:
+
 1. An action `requestSomething`, to toggle the loading state
 1. An action `receiveSomethingSuccess`, to handle the success callback
 1. An action `receiveSomethingError`, to handle the error callback
 1. An action `fetchSomething` to make the request.
     1. In case your application does more than a `GET` request you can use these as examples:
-        1. `PUT`: `createSomething`
-        2. `POST`: `updateSomething`
-        3. `DELETE`: `deleteSomething`
+        - `PUT`: `createSomething`
+        - `POST`: `updateSomething`
+        - `DELETE`: `deleteSomething`
 
 The component MUST only dispatch the `fetchNamespace` action. Actions namespaced with `request` or `receive` should not be called from the component
 The `fetch` action will be responsible to dispatch `requestNamespace`, `receiveNamespaceSuccess` and `receiveNamespaceError`
 
 By following this pattern we guarantee:
+
 1. All applications follow the same pattern, making it easier for anyone to maintain the code
 1. All data in the application follows the same lifecycle pattern
 1. Actions are contained and human friendly
@@ -297,12 +299,12 @@ export default {
 
     ```javascript
       // component.vue
-  
+
       // bad
       created() {
         this.$store.commit('mutation');
       }
-  
+
       // good
       created() {
         this.$store.dispatch('action');
diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md
index 0d558583bb8e280bed4b97c23f8deb95761170d3..e860bde48dc7b25aa6a9d7fc6810ff5081cb14c2 100644
--- a/doc/development/github_importer.md
+++ b/doc/development/github_importer.md
@@ -99,8 +99,8 @@ This worker will wrap up the import process by performing some housekeeping
 
 Advancing stages is done in one of two ways:
 
-1. Scheduling the worker for the next stage directly.
-2. Scheduling a job for `Gitlab::GithubImport::AdvanceStageWorker` which will
+- Scheduling the worker for the next stage directly.
+- Scheduling a job for `Gitlab::GithubImport::AdvanceStageWorker` which will
    advance the stage when all work of the current stage has been completed.
 
 The first approach should only be used by workers that perform all their work in
@@ -147,7 +147,7 @@ We handle this by doing the following:
 
 1. Once we hit the rate limit all jobs will automatically reschedule themselves
    in such a way that they are not executed until the rate limit has been reset.
-2. We cache the mapping of GitHub users to GitLab users in Redis.
+1. We cache the mapping of GitHub users to GitLab users in Redis.
 
 More information on user caching can be found below.
 
@@ -157,21 +157,21 @@ When mapping GitHub users to GitLab users we need to (in the worst case)
 perform:
 
 1. One API call to get the user's Email address.
-2. Two database queries to see if a corresponding GitLab user exists. One query
+1. Two database queries to see if a corresponding GitLab user exists. One query
    will try to find the user based on the GitHub user ID, while the second query
    is used to find the user using their GitHub Email address.
 
 Because this process is quite expensive we cache the result of these lookups in
 Redis. For every user looked up we store three keys:
 
-1. A Redis key mapping GitHub usernames to their Email addresses.
-2. A Redis key mapping a GitHub Email addresses to a GitLab user ID.
-3. A Redis key mapping a GitHub user ID to GitLab user ID.
+- A Redis key mapping GitHub usernames to their Email addresses.
+- A Redis key mapping a GitHub Email addresses to a GitLab user ID.
+- A Redis key mapping a GitHub user ID to GitLab user ID.
 
 There are two types of lookups we cache:
 
-1. A positive lookup, meaning we found a GitLab user ID.
-2. A negative lookup, meaning we didn't find a GitLab user ID. Caching this
+- A positive lookup, meaning we found a GitLab user ID.
+- A negative lookup, meaning we didn't find a GitLab user ID. Caching this
    prevents us from performing the same work for users that we know don't exist
    in our GitLab database.
 
diff --git a/doc/development/instrumentation.md b/doc/development/instrumentation.md
index 7761f65d78aae833653be72759034ad3f61dcd42..bef166f2aec669070a4005aeba9dc71d5d9d7f4e 100644
--- a/doc/development/instrumentation.md
+++ b/doc/development/instrumentation.md
@@ -117,11 +117,11 @@ The block is executed and the execution time is stored as a set of fields in the
 currently running transaction. If no transaction is present the block is yielded
 without measuring anything.
 
-3 values are measured for a block:
+Three values are measured for a block:
 
-1. The real time elapsed, stored in NAME_real_time.
-2. The CPU time elapsed, stored in NAME_cpu_time.
-3. The call count, stored in NAME_call_count.
+- The real time elapsed, stored in NAME_real_time.
+- The CPU time elapsed, stored in NAME_cpu_time.
+- The call count, stored in NAME_call_count.
 
 Both the real and CPU timings are measured in milliseconds.
 
diff --git a/doc/development/new_fe_guide/development/performance.md b/doc/development/new_fe_guide/development/performance.md
index 244dfb3756fb2f911b3afe1de78350389b0a3c6c..5ccd5357314e67bbcaf2376b7b7e54054fc6bd27 100644
--- a/doc/development/new_fe_guide/development/performance.md
+++ b/doc/development/new_fe_guide/development/performance.md
@@ -2,7 +2,7 @@
 
 ## Monitoring
 
-We have a performance dashboard available in one of our [grafana instances](https://performance.gprd.gitlab.com/dashboard/db/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://sitespeed.io) every 6 hours. These changes are displayed after a set number of pages are aggregated.
+We have a performance dashboard available in one of our [grafana instances](https://dashboards.gitlab.net/d/1EBTz3Dmz/sitespeed-page-summary?orgId=1). This dashboard automatically aggregates metric data from [sitespeed.io](https://sitespeed.io) every 6 hours. These changes are displayed after a set number of pages are aggregated.
 
 These pages can be found inside a text file in the gitlab-build-images [repository](https://gitlab.com/gitlab-org/gitlab-build-images) called [gitlab.txt](https://gitlab.com/gitlab-org/gitlab-build-images/blob/master/scripts/gitlab.txt)
 Any frontend engineer can contribute to this dashboard. They can contribute by adding or removing urls of pages from this text file. Please have a [frontend monitoring expert](https://about.gitlab.com/team) review your changes before assigning to a maintainer of the `gitlab-build-images` project. The changes will go live on the next scheduled run after the changes are merged into `master`.
diff --git a/doc/development/new_fe_guide/development/testing.md b/doc/development/new_fe_guide/development/testing.md
index a9223ac6b0f84f8e22d0418f85d3887a9050c773..748478768de04eb1a3ecfa8f5b67d88924240299 100644
--- a/doc/development/new_fe_guide/development/testing.md
+++ b/doc/development/new_fe_guide/development/testing.md
@@ -1,30 +1,247 @@
 # Overview of Frontend Testing
 
-## Types of tests in our codebase
+Tests relevant for frontend development can be found at two places:
+
+- `spec/javascripts/` which are run by Karma and contain
+  - [frontend unit tests](#frontend-unit-tests)
+  - [frontend component tests](#frontend-component-tests)
+  - [frontend integration tests](#frontend-integration-tests)
+- `spec/features/` which are run by RSpec and contain
+  - [feature tests](#feature-tests)
+
+In addition there were feature tests in `features/` run by Spinach in the past.
+These have been removed from our codebase in May 2018 ([#23036](https://gitlab.com/gitlab-org/gitlab-ce/issues/23036)).
+
+See also:
 
-* **RSpec**
-  * **[Ruby unit tests](#ruby-unit-tests-spec-rb)** for models, controllers, helpers, etc. (`/spec/**/*.rb`)
-  * **[Full feature tests](#full-feature-tests-spec-features-rb)** (`/spec/features/**/*.rb`)
-* **[Karma](#karma-tests-spec-javascripts-js)** (`/spec/javascripts/**/*.js`)
-* <s>Spinach</s> — These have been removed from our codebase in May 2018. (`/features/`)
+- [old testing guide](../../testing_guide/frontend_testing.html)
+- [notes on testing Vue components](../../fe_guide/vue.html#testing-vue-components)
 
-## RSpec: Ruby unit tests `/spec/**/*.rb`
+## Frontend unit tests
 
-These tests are meant to unit test the ruby models, controllers and helpers.
+Unit tests are on the lowest abstraction level and typically test functionality that is not directly perceivable by a user.
 
-### When do we write/update these tests?
+### When to use unit tests
 
-Whenever we create or modify any Ruby models, controllers or helpers we add/update corresponding tests.
+<details>
+  <summary>exported functions and classes</summary>
+  Anything that is exported can be reused at various places in a way you have no control over.
+  Therefore it is necessary to document the expected behavior of the public interface with tests.
+</details>
 
----
+<details>
+  <summary>Vuex actions</summary>
+  Any Vuex action needs to work in a consistent way independent of the component it is triggered from.
+</details>
 
-## RSpec: Full feature tests `/spec/features/**/*.rb`
+<details>
+  <summary>Vuex mutations</summary>
+  For complex Vuex mutations it helps to identify the source of a problem by separating the tests from other parts of the Vuex store.
+</details>
 
-Full feature tests will load a full app environment and allow us to test things like rendering DOM, interacting with links and buttons, testing the outcome of those interactions through multiple pages if necessary. These are also called end-to-end tests but should not be confused with QA end-to-end tests (`package-and-qa` manual pipeline job).
+### When *not* to use unit tests
 
-### When do we write/update these tests?
+<details>
+  <summary>non-exported functions or classes</summary>
+  Anything that is not exported from a module can be considered private or an implementation detail and doesn't need to be tested.
+</details>
 
-When we add a new feature, we write at least two tests covering the success and the failure scenarios.
+<details>
+  <summary>constants</summary>
+  Testing the value of a constant would mean to copy it.
+  This results in extra effort without additional confidence that the value is correct.
+</details>
+
+<details>
+  <summary>Vue components</summary>
+  Computed properties, methods, and lifecycle hooks can be considered an implementation detail of components and don't need to be tested.
+  They are implicitly covered by component tests.
+  The <a href="https://vue-test-utils.vuejs.org/guides/#getting-started">official Vue guidelines</a> suggest the same.
+</details>
+
+### What to mock in unit tests
+
+<details>
+  <summary>state of the class under test</summary>
+  Modifying the state of the class under test directly rather than using methods of the class avoids side-effects in test setup.
+</details>
+
+<details>
+  <summary>other exported classes</summary>
+  Every class needs to be tested in isolation to prevent test scenarios from growing exponentially.
+</details>
+
+<details>
+  <summary>single DOM elements if passed as parameters</summary>
+  For tests that only operate on single DOM elements rather than a whole page, creating these elements is cheaper than loading a whole HTML fixture.
+</details>
+
+<details>
+  <summary>all server requests</summary>
+  When running frontend unit tests, the backend may not be reachable.
+  Therefore all outgoing requests need to be mocked.
+</details>
+
+<details>
+  <summary>asynchronous background operations</summary>
+  Background operations cannot be stopped or waited on, so they will continue running in the following tests and cause side effects.
+</details>
+
+### What *not* to mock in unit tests
+
+<details>
+  <summary>non-exported functions or classes</summary>
+  Everything that is not exported can be considered private to the module and will be implicitly tested via the exported classes / functions.
+</details>
+
+<details>
+  <summary>methods of the class under test</summary>
+  By mocking methods of the class under test, the mocks will be tested and not the real methods.
+</details>
+
+<details>
+  <summary>utility functions (pure functions, or those that only modify parameters)</summary>
+  If a function has no side effects because it has no state, it is safe to not mock it in tests.
+</details>
+
+<details>
+  <summary>full HTML pages</summary>
+  Loading the HTML of a full page slows down tests, so it should be avoided in unit tests.
+</details>
+
+## Frontend component tests
+
+Component tests cover the state of a single component that is perceivable by a user depending on external signals such as user input, events fired from other components, or application state.
+
+### When to use component tests
+
+- Vue components
+
+### When *not* to use component tests
+
+<details>
+  <summary>Vue applications</summary>
+  Vue applications may contain many components.
+  Testing them on a component level requires too much effort.
+  Therefore they are tested on frontend integration level.
+</details>
+
+<details>
+  <summary>HAML templates</summary>
+  HAML templates contain only Markup and no frontend-side logic.
+  Therefore they are not complete components.
+</details>
+
+### What to mock in component tests
+
+<details>
+  <summary>DOM</summary>
+  Operating on the real DOM is significantly slower than on the virtual DOM.
+</details>
+
+<details>
+  <summary>properties and state of the component under test</summary>
+  Similarly to testing classes, modifying the properties directly (rather than relying on methods of the component) avoids side-effects.
+</details>
+
+<details>
+  <summary>Vuex store</summary>
+  To avoid side effects and keep component tests simple, Vuex stores are replaced with mocks.
+</details>
+
+<details>
+  <summary>all server requests</summary>
+  Similar to unit tests, when running component tests, the backend may not be reachable.
+  Therefore all outgoing requests need to be mocked.
+</details>
+
+<details>
+  <summary>asynchronous background operations</summary>
+  Similar to unit tests, background operations cannot be stopped or waited on, so they will continue running in the following tests and cause side effects.
+</details>
+
+<details>
+  <summary>child components</summary>
+  Every component is tested individually, so child components are mocked.
+  See also <a href="https://vue-test-utils.vuejs.org/api/#shallowmount">shallowMount()</a>
+</details>
+
+### What *not* to mock in component tests
+
+<details>
+  <summary>methods or computed properties of the component under test</summary>
+  By mocking part of the component under test, the mocks will be tested and not the real component.
+</details>
+
+<details>
+  <summary>functions and classes independent from Vue</summary>
+  All plain JavaScript code is already covered by unit tests and needs not to be mocked in component tests.
+</details>
+
+## Frontend integration tests
+
+Integration tests cover the interaction between all components on a single page.
+Their abstraction level is comparable to how a user would interact with the UI.
+
+### When to use integration tests
+
+<details>
+  <summary>page bundles (<code>index.js</code> files in <code>app/assets/javascripts/pages/</code>)</summary>
+  Testing the page bundles ensures the corresponding frontend components integrate well.
+</details>
+
+<details>
+  <summary>Vue applications outside of page bundles</summary>
+  Testing Vue applications as a whole ensures the corresponding frontend components integrate well.
+</details>
+
+### What to mock in integration tests
+
+<details>
+  <summary>HAML views (use fixtures instead)</summary>
+  Rendering HAML views requires a Rails environment including a running database which we cannot rely on in frontend tests.
+</details>
+
+<details>
+  <summary>all server requests</summary>
+  Similar to unit and component tests, when running component tests, the backend may not be reachable.
+  Therefore all outgoing requests need to be mocked.
+</details>
+
+<details>
+  <summary>asynchronous background operations that are not perceivable on the page</summary>
+  Background operations that affect the page need to be tested on this level.
+  All other background operations cannot be stopped or waited on, so they will continue running in the following tests and cause side effects.
+</details>
+
+### What *not* to mock in integration tests
+
+<details>
+  <summary>DOM</summary>
+  Testing on the real DOM ensures our components work in the environment they are meant for.
+  Part of this will be delegated to <a href="https://gitlab.com/gitlab-org/quality/team-tasks/issues/45">cross-browser testing</a>.
+</details>
+
+<details>
+  <summary>properties or state of components</summary>
+  On this level, all tests can only perform actions a user would do.
+  For example to change the state of a component, a click event would be fired.
+</details>
+
+<details>
+  <summary>Vuex stores</summary>
+  When testing the frontend code of a page as a whole, the interaction between Vue components and Vuex stores is covered as well.
+<details>
+
+## Feature tests
+
+In contrast to [frontend integration tests](#frontend-integration-tests), feature tests make requests against the real backend instead of using fixtures.
+This also implies that database queries are executed which makes this category significantly slower.
+
+### When to use feature tests
+
+- use cases that require a backend and cannot be tested using fixtures
+- behavior that is not part of a page bundle but defined globally
 
 ### Relevant notes
 
@@ -48,33 +265,9 @@ wait_for_requests
 expect(page).not_to have_selector('.card')
 ```
 
----
-
-## Karma tests `/spec/javascripts/**/*.js`
-
-These are the more frontend-focused, at the moment. They're **faster** than `rspec` and make for very quick testing of frontend components.
-
-### When do we write/update these tests?
-
-When we add/update a method/action/mutation to Vue or Vuex, we write karma tests to ensure the logic we wrote doesn't break. We should, however, refrain from writing tests that double-test Vue's internal features.
-
-### Relevant notes
-
-Karma tests are run against a virtual DOM.
+## Test helpers
 
-To populate the DOM, we can use fixtures to fake the generation of HTML instead of having Rails do that.
-
-Be sure to check the [best practices for karma tests](../../testing_guide/frontend_testing.html#best-practices).
-
-### Vue and Vuex
-
-Test as much as possible without double-testing Vue's internal features, as mentioned above.
-
-Make sure to test computedProperties, mutations, actions. Run the action and test that the proper mutations are committed.
-
-Also check these [notes on testing Vue components](../../fe_guide/vue.html#testing-vue-components).
-
-#### Vuex Helper: `testAction`
+### Vuex Helper: `testAction`
 
 We have a helper available to make testing actions easier, as per [official documentation](https://vuex.vuejs.org/en/testing.html):
 
@@ -97,7 +290,7 @@ testAction(
 
 Check an example in [spec/javascripts/ide/stores/actions_spec.jsspec/javascripts/ide/stores/actions_spec.js](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/javascripts/ide/stores/actions_spec.js).
 
-#### Vue Helper: `mountComponent`
+### Vue Helper: `mountComponent`
 
 To make mounting a Vue component easier and more readable, we have a few helpers available in `spec/helpers/vue_mount_component_helper`.
 
@@ -133,6 +326,7 @@ afterEach(() => {
   vm.$destroy();
 });
 ```
+
 ## Testing with older browsers
 
 Some regressions only affect a specific browser version. We can install and test in particular browsers with either Firefox or Browserstack using the following steps:
@@ -140,20 +334,21 @@ Some regressions only affect a specific browser version. We can install and test
 
 ### Browserstack
 
-[Browserstack](https://www.browserstack.com/) allows you to test more than 1200 mobile devices and browsers. 
+[Browserstack](https://www.browserstack.com/) allows you to test more than 1200 mobile devices and browsers.
 You can use it directly through the [live app](https://www.browserstack.com/live) or you can install the [chrome extension](https://chrome.google.com/webstore/detail/browserstack/nkihdmlheodkdfojglpcjjmioefjahjb) for easy access.
 You can find the credentials on 1Password, under `frontendteam@gitlab.com`.
 
 ### Firefox
 
 #### macOS
+
 You can download any older version of Firefox from the releases FTP server, https://ftp.mozilla.org/pub/firefox/releases/
 
 1. From the website, select a version, in this case `50.0.1`.
-2. Go to the mac folder.
-3. Select your preferred language, you will find the dmg package inside, download it.
-4. Drag and drop the application to any other folder but the `Applications` folder.
-5. Rename the application to something like `Firefox_Old`.
-6. Move the application to the `Applications` folder.
-7. Open up a terminal and run `/Applications/Firefox_Old.app/Contents/MacOS/firefox-bin -profilemanager` to create a new profile specific to that Firefox version.
-8. Once the profile has been created, quit the app, and run it again like normal. You now have a working older Firefox version.
+1. Go to the mac folder.
+1. Select your preferred language, you will find the dmg package inside, download it.
+1. Drag and drop the application to any other folder but the `Applications` folder.
+1. Rename the application to something like `Firefox_Old`.
+1. Move the application to the `Applications` folder.
+1. Open up a terminal and run `/Applications/Firefox_Old.app/Contents/MacOS/firefox-bin -profilemanager` to create a new profile specific to that Firefox version.
+1. Once the profile has been created, quit the app, and run it again like normal. You now have a working older Firefox version.
diff --git a/doc/development/performance.md b/doc/development/performance.md
index e738f2b4b666942f190deec859b6f48e8ed8b5bf..4cc2fdc9a58ccd0f9463a380c7d13628253b9d64 100644
--- a/doc/development/performance.md
+++ b/doc/development/performance.md
@@ -9,17 +9,17 @@ The process of solving performance problems is roughly as follows:
 
 1. Make sure there's an issue open somewhere (e.g., on the GitLab CE issue
    tracker), create one if there isn't. See [#15607][#15607] for an example.
-2. Measure the performance of the code in a production environment such as
+1. Measure the performance of the code in a production environment such as
    GitLab.com (see the [Tooling](#tooling) section below). Performance should be
    measured over a period of _at least_ 24 hours.
-3. Add your findings based on the measurement period (screenshots of graphs,
+1. Add your findings based on the measurement period (screenshots of graphs,
    timings, etc) to the issue mentioned in step 1.
-4. Solve the problem.
-5. Create a merge request, assign the "Performance" label and assign it to
+1. Solve the problem.
+1. Create a merge request, assign the "Performance" label and assign it to
    [@yorickpeterse][yorickpeterse] for reviewing.
-6. Once a change has been deployed make sure to _again_ measure for at least 24
+1. Once a change has been deployed make sure to _again_ measure for at least 24
    hours to see if your changes have any impact on the production environment.
-7. Repeat until you're done.
+1. Repeat until you're done.
 
 When providing timings make sure to provide:
 
@@ -94,14 +94,14 @@ result of this should be used instead of the `Benchmark` module.
 
 In short:
 
-1. Don't trust benchmarks you find on the internet.
-2. Never make claims based on just benchmarks, always measure in production to
+- Don't trust benchmarks you find on the internet.
+- Never make claims based on just benchmarks, always measure in production to
    confirm your findings.
-3. X being N times faster than Y is meaningless if you don't know what impact it
+- X being N times faster than Y is meaningless if you don't know what impact it
    will actually have on your production environment.
-4. A production environment is the _only_ benchmark that always tells the truth
+- A production environment is the _only_ benchmark that always tells the truth
    (unless your performance monitoring systems are not set up correctly).
-5. If you must write a benchmark use the benchmark-ips Gem instead of Ruby's
+- If you must write a benchmark use the benchmark-ips Gem instead of Ruby's
    `Benchmark` module.
 
 ## Profiling
diff --git a/doc/development/post_deployment_migrations.md b/doc/development/post_deployment_migrations.md
index cfc91539beee3cc2649cd0149e2931439252374f..5986efa9974fcdc8c9cfcafc3f89a96ecd314678 100644
--- a/doc/development/post_deployment_migrations.md
+++ b/doc/development/post_deployment_migrations.md
@@ -57,13 +57,13 @@ depends on this column being present while it's running. Normally you'd follow
 these steps in such a case:
 
 1. Stop the GitLab instance
-2. Run the migration removing the column
-3. Start the GitLab instance again
+1. Run the migration removing the column
+1. Start the GitLab instance again
 
 Using post deployment migrations we can instead follow these steps:
 
 1. Deploy a new version of GitLab while ignoring post deployment migrations
-2. Re-run `rake db:migrate` but without the environment variable set
+1. Re-run `rake db:migrate` but without the environment variable set
 
 Here we don't need any downtime as the migration takes place _after_ a new
 version (which doesn't depend on the column anymore) has been deployed.
diff --git a/doc/development/query_count_limits.md b/doc/development/query_count_limits.md
index 310e3faf61b1d0a612ae05af434c44e4803db459..b3ecaf30d8a06d1709fb9ab05c03286bcb328f7f 100644
--- a/doc/development/query_count_limits.md
+++ b/doc/development/query_count_limits.md
@@ -8,8 +8,8 @@ in test environments we'll raise an error when this threshold is exceeded.
 When a test fails because it executes more than 100 SQL queries there are two
 solutions to this problem:
 
-1. Reduce the number of SQL queries that are executed.
-2. Whitelist the controller or API endpoint.
+- Reduce the number of SQL queries that are executed.
+- Whitelist the controller or API endpoint.
 
 You should only resort to whitelisting when an existing controller or endpoint
 is to blame as in this case reducing the number of SQL queries can take a lot of
diff --git a/doc/development/swapping_tables.md b/doc/development/swapping_tables.md
index 6b990ece72c37c920f0c85deb33989f88c06badd..29cd6a43affeafa043cd1bf83165c83e6db5ffca 100644
--- a/doc/development/swapping_tables.md
+++ b/doc/development/swapping_tables.md
@@ -8,8 +8,8 @@ Let's say you want to swap the table "events" with "events_for_migration". In
 this case you need to follow 3 steps:
 
 1. Rename "events" to "events_temporary"
-2. Rename "events_for_migration" to "events"
-3. Rename "events_temporary" to "events_for_migration"
+1. Rename "events_for_migration" to "events"
+1. Rename "events_temporary" to "events_for_migration"
 
 Rails allows you to do this using the `rename_table` method:
 
diff --git a/doc/development/ui_guide.md b/doc/development/ui_guide.md
index df6ac452300988202a2b36853b1461bb3b2bbac7..dd206bb2ae9cfddc7d69dd3a1cb4759c386344c9 100644
--- a/doc/development/ui_guide.md
+++ b/doc/development/ui_guide.md
@@ -54,12 +54,12 @@ information from database or file system
 
 When exporting SVGs, be sure to follow the following guidelines:
 
-1. Convert all strokes to outlines.
-2. Use pathfinder tools to combine overlapping paths and create compound paths.
-3. SVGs that are limited to one color should be exported without a fill color so the color can be set using CSS.
-4. Ensure that exported SVGs have been run through an [SVG cleaner](https://github.com/RazrFalcon/SVGCleaner) to remove unused elements and attributes.
+- Convert all strokes to outlines.
+- Use pathfinder tools to combine overlapping paths and create compound paths.
+- SVGs that are limited to one color should be exported without a fill color so the color can be set using CSS.
+- Ensure that exported SVGs have been run through an [SVG cleaner](https://github.com/RazrFalcon/SVGCleaner) to remove unused elements and attributes.
 
-You can open your svg in a text editor to ensure that it is clean. 
+You can open your svg in a text editor to ensure that it is clean.
 Incorrect files will look like this:
 
 ```xml
diff --git a/doc/development/ux_guide/users.md b/doc/development/ux_guide/users.md
index f9c395b2dfffd7717d962cd2cb0c3469ed05030f..30386e728c432b0fba0c9778d5c04785b8a32b2a 100644
--- a/doc/development/ux_guide/users.md
+++ b/doc/development/ux_guide/users.md
@@ -101,7 +101,7 @@ GitLab's interface initially attracted Nazim when he was comparing version contr
 ### Demographics
 
 **Age**
- 
+
 42 years old
 
 **Location**
@@ -148,11 +148,11 @@ Matthieu describes GitLab as:
 >"the only tool that offers the real feeling of having everything you need in one place."
 
 
-He credits himself as being entirely responsible for moving his company to GitLab. 
+He credits himself as being entirely responsible for moving his company to GitLab.
 
 ### Frustrations
 #### Updating to the latest release
-Matthieu introduced his company to GitLab. He is responsible for maintaining and managing the company's installation in addition to his day job. He feels updates are too frequent and he doesn't always have sufficient time to update GitLab. As a result, he's not up to date with releases. 
+Matthieu introduced his company to GitLab. He is responsible for maintaining and managing the company's installation in addition to his day job. He feels updates are too frequent and he doesn't always have sufficient time to update GitLab. As a result, he's not up to date with releases.
 
 Matthieu tried to set up automatic updates, however, as he isn't a Systems Administrator, he wasn't confident in his setup. He feels he should be able to "upgrade without users even noticing" but hasn't figured out how to do this yet. Matthieu would like the "update process to be triggered from the Admin Panel, perhaps accompanied with a changelog and the option to skip updates."
 
@@ -173,11 +173,11 @@ It's Matthieu's responsibility to get teams across his organization up and runni
 He states that there has been: "a sluggishness of others to adapt" and it's "a low-effort adaptation at that."
 
 ### Goals
-* To save time. One of the reasons Matthieu moved his company to GitLab was to reduce the effort it took him to manage and configure multiple tools, thus saving him time. He has to balance his day job in addition to managing the company's GitLab installation and onboarding new teams to GitLab. 
-* To use a platform which is easy to manage. Matthieu isn't a Systems Administrator, and when updating GitLab, creating backups, etc. He would prefer to work within GitLab's UI. Explanations / guided instructions when configuring settings in GitLab's interface would really help Matthieu. He needs reassurance that what he is about to change is 
+* To save time. One of the reasons Matthieu moved his company to GitLab was to reduce the effort it took him to manage and configure multiple tools, thus saving him time. He has to balance his day job in addition to managing the company's GitLab installation and onboarding new teams to GitLab.
+* To use a platform which is easy to manage. Matthieu isn't a Systems Administrator, and when updating GitLab, creating backups, etc. He would prefer to work within GitLab's UI. Explanations / guided instructions when configuring settings in GitLab's interface would really help Matthieu. He needs reassurance that what he is about to change is
 
-1. the right setting
-2. will provide him with the desired result he wants.
+- The right setting.
+- Will provide him with the desired result he wants.
 
 * Matthieu needs to educate his colleagues about GitLab. Matthieu's colleagues won't adopt GitLab as they're unaware of its capabilities and the positive impact it could have on their work. Matthieu needs support in getting this message across to them.
 
@@ -307,4 +307,4 @@ Karolina has an interest in UX and therefore has strong opinions about how GitLa
 ### Goals
 * To develop her programming experience and to learn from other developers.
 * To contribute to both her own and other open source projects.
-* To use a fast and intuitive version control platform.
\ No newline at end of file
+* To use a fast and intuitive version control platform.
diff --git a/doc/development/what_requires_downtime.md b/doc/development/what_requires_downtime.md
index b668c9de6a0078855e7ae7aeeb362a79fd03321e..3630a28fae9cd75d79394ea1c2137a1c06e2867f 100644
--- a/doc/development/what_requires_downtime.md
+++ b/doc/development/what_requires_downtime.md
@@ -300,7 +300,7 @@ The same applies to `rename_column_using_background_migration`:
 
 1. Create a migration using the helper, which will schedule background
    migrations to spread the writes over a longer period of time.
-2. In the next monthly release, create a clean-up migration to steal from the
+1. In the next monthly release, create a clean-up migration to steal from the
    Sidekiq queues, migrate any missing rows, and cleanup the rename. This
    migration should skip the steps after stealing from the Sidekiq queues if the
    column has already been renamed.
diff --git a/doc/gitlab-basics/create-your-ssh-keys.md b/doc/gitlab-basics/create-your-ssh-keys.md
index b6ebe374de31bc1bea11a412b0cab027f0fdf11e..881629c3bfdac64c284f02f556f04b60dccaad7b 100644
--- a/doc/gitlab-basics/create-your-ssh-keys.md
+++ b/doc/gitlab-basics/create-your-ssh-keys.md
@@ -12,7 +12,7 @@
 
     ![SSH Keys](img/profile_settings_ssh_keys.png)
 
-3. Paste your **public** key that you generated in the first step in the 'Key'
+1. Paste your **public** key that you generated in the first step in the 'Key'
    box.
 
     ![Paste SSH public key](img/profile_settings_ssh_keys_paste_pub.png)
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 316411d10470ce675ff426adf10748ce9e2b9d12..cac97b63d927fe2cd0699b19d3e974f518699e61 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -132,9 +132,9 @@ Remove the old Ruby 1.8 if present:
 Download Ruby and compile it:
 
     mkdir /tmp/ruby && cd /tmp/ruby
-    curl --remote-name --progress https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.5.tar.gz
-    echo '4d650f302f1ec00256450b112bb023644b6ab6dd  ruby-2.4.5.tar.gz' | shasum -c - && tar xzf ruby-2.4.5.tar.gz
-    cd ruby-2.4.5
+    curl --remote-name --progress https://cache.ruby-lang.org/pub/ruby/2.5/ruby-2.5.3.tar.gz
+    echo 'f919a9fbcdb7abecd887157b49833663c5c15fda  ruby-2.5.3.tar.gz' | shasum -c - && tar xzf ruby-2.5.3.tar.gz
+    cd ruby-2.5.3
 
     ./configure --disable-install-rdoc
     make
diff --git a/doc/integration/akismet.md b/doc/integration/akismet.md
index a6436b5f9260a4bdee644076b7c7b4ae2d6477be..200fe6f52062c2e18126ad1f0bef64de8fa1a459 100644
--- a/doc/integration/akismet.md
+++ b/doc/integration/akismet.md
@@ -20,17 +20,17 @@ To use Akismet:
 
 1. Go to the URL: https://akismet.com/account/
 
-2. Sign-in or create a new account.
+1. Sign-in or create a new account.
 
-3. Click on **Show** to reveal the API key.
+1. Click on **Show** to reveal the API key.
 
-4. Go to Applications Settings on Admin Area (`admin/application_settings`)
+1. Go to Applications Settings on Admin Area (`admin/application_settings`)
 
-5. Check the **Enable Akismet** checkbox
+1. Check the **Enable Akismet** checkbox
 
-6. Fill in the API key from step 3.
+1. Fill in the API key from step 3.
 
-7. Save the configuration.
+1. Save the configuration.
 
 ![Screenshot of Akismet settings](img/akismet_settings.png)
 
@@ -42,9 +42,9 @@ To use Akismet:
 As a way to better recognize between spam and ham, you can train the Akismet
 filter whenever there is a false positive or false negative.
 
-When an entry is recognized as spam, it is rejected and added to the Spam Logs. 
+When an entry is recognized as spam, it is rejected and added to the Spam Logs.
 From here you can review if they are really spam. If one of them is not really
-spam, you can use the **Submit as ham** button to tell Akismet that it falsely 
+spam, you can use the **Submit as ham** button to tell Akismet that it falsely
 recognized an entry as spam.
 
 ![Screenshot of Spam Logs](img/spam_log.png)
diff --git a/doc/integration/recaptcha.md b/doc/integration/recaptcha.md
index 932cd479d56270a5237e59fea152fac74c42e749..8fdadb008ec83b9003a93720a93ed13a913044ae 100644
--- a/doc/integration/recaptcha.md
+++ b/doc/integration/recaptcha.md
@@ -8,19 +8,13 @@ to confirm that a real user, not a bot, is attempting to create an account.
 
 To use reCAPTCHA, first you must create a site and private key.
 
-1. Go to the URL: https://www.google.com/recaptcha/admin
-
-2. Fill out the form necessary to obtain reCAPTCHA keys.
-
-3. Login to your GitLab server, with administrator credentials.
-
-4. Go to Applications Settings on Admin Area (`admin/application_settings`)
-
-5. Fill all recaptcha fields with keys from previous steps
-
-6. Check the `Enable reCAPTCHA` checkbox
-
-7. Save the configuration.
+1. Go to the URL: <https://www.google.com/recaptcha/admin>.
+1. Fill out the form necessary to obtain reCAPTCHA keys.
+1. Login to your GitLab server, with administrator credentials.
+1. Go to Applications Settings on Admin Area (`admin/application_settings`).
+1. Fill all recaptcha fields with keys from previous steps.
+1. Check the `Enable reCAPTCHA` checkbox.
+1. Save the configuration.
 
 ## Enabling reCAPTCHA for user logins via passwords
 
diff --git a/doc/security/rack_attack.md b/doc/security/rack_attack.md
index 3efb19c1526f1530218e50de7e05c2a7034d64c4..07e7b3da13b22e17f40d7b44377ecab5716f8c61 100644
--- a/doc/security/rack_attack.md
+++ b/doc/security/rack_attack.md
@@ -10,7 +10,7 @@ Rack Attack offers IP whitelisting, blacklisting, Fail2ban style filtering and
 tracking.
 
 **Note:** Starting with 11.2, Rack Attack is disabled by default. To continue
-using this feature, please enable it in your `gitlab.rb` by setting 
+using this feature, please enable it in your `gitlab.rb` by setting
 `gitlab_rails['rack_attack_git_basic_auth'] = true`.
 
 By default, user sign-in, user sign-up (if enabled), and user password reset is
@@ -41,7 +41,7 @@ For more information on how to use these options check out
     }
     ```
 
-3. Reconfigure GitLab:
+1. Reconfigure GitLab:
 
     ```
     sudo gitlab-ctl reconfigure
@@ -98,26 +98,26 @@ In case you want to remove a blocked IP, follow these steps:
     grep "Rack_Attack" /var/log/gitlab/gitlab-rails/production.log
     ```
 
-2. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
+1. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
 
     ```sh
     /opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
     ```
 
-3. You can remove the block using the following syntax, replacing `<ip>` with
+1. You can remove the block using the following syntax, replacing `<ip>` with
    the actual IP that is blacklisted:
 
     ```
     del cache:gitlab:rack::attack:allow2ban:ban:<ip>
     ```
 
-4. Confirm that the key with the IP no longer shows up:
+1. Confirm that the key with the IP no longer shows up:
 
     ```
     keys *rack::attack*
     ```
 
-5. Optionally, add the IP to the whitelist to prevent it from being blacklisted
+1. Optionally, add the IP to the whitelist to prevent it from being blacklisted
    again (see [settings](#settings)).
 
 ## Troubleshooting
@@ -129,11 +129,11 @@ the load balancer. In that case, you will need to:
 
 1. [Configure `nginx[real_ip_trusted_addresses]`](https://docs.gitlab.com/omnibus/settings/nginx.html#configuring-gitlab-trusted_proxies-and-the-nginx-real_ip-module).
    This will keep users' IPs from being listed as the load balancer IPs.
-2. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
-3. Reconfigure GitLab:
+1. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
+1. Reconfigure GitLab:
 
     ```
     sudo gitlab-ctl reconfigure
     ```
 
-4. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)
+1. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)
diff --git a/doc/security/two_factor_authentication.md b/doc/security/two_factor_authentication.md
index cd290a80314abc72f798e5cb5622398fba92e1d9..b770f2544d2b8361c11b2c89909b20c61997aad7 100644
--- a/doc/security/two_factor_authentication.md
+++ b/doc/security/two_factor_authentication.md
@@ -13,8 +13,8 @@ You can read more about it here:
 Users on GitLab, can enable it without any admin's intervention. If you want to
 enforce everyone to set up 2FA, you can choose from two different ways:
 
- 1. Enforce on next login
- 2. Suggest on next login, but allow a grace period before enforcing.
+- Enforce on next login.
+- Suggest on next login, but allow a grace period before enforcing.
 
 In the Admin area under **Settings** (`/admin/application_settings`), look for
 the "Sign-in Restrictions" area, where you can configure both.
diff --git a/doc/university/training/end-user/README.md b/doc/university/training/end-user/README.md
index e5eb5d97e3b22ad46956bb67cdc229402c426b4c..701533358c8f473f702d2e120d2e833683031756 100644
--- a/doc/university/training/end-user/README.md
+++ b/doc/university/training/end-user/README.md
@@ -78,7 +78,7 @@ Workshop Time!
 ```bash
 git config --global user.name "Your Name"
 git config --global user.email you@example.com
-```    
+```
 
 - If you don't use the global flag you can set up a different author for
   each project
@@ -107,14 +107,14 @@ cd ~/development
 -or-
 
 mkdir ~/workspace
-cd ~/workspace  
+cd ~/workspace
 ```
 
 ---
 
 ## Git Basics
 
----  
+---
 
 ### Git Workflow
 
@@ -136,7 +136,7 @@ cd ~/workspace
   issue tracking, Merge Requests, and other features.
 - The hosted version of GitLab is gitlab.com
 
----  
+---
 
 ### New Project
 
@@ -150,12 +150,12 @@ cd ~/workspace
 ### Git and GitLab basics
 
 1. Edit `edit_this_file.rb` in `training-examples`
-2. See it listed as a changed file (working area)
-3. View the differences
-4. Stage the file
-5. Commit
-6. Push the commit to the remote
-7. View the git log
+1. See it listed as a changed file (working area)
+1. View the differences
+1. Stage the file
+1. Commit
+1. Push the commit to the remote
+1. View the git log
 
 ---
 
@@ -169,14 +169,14 @@ git push origin master
 git log
 ```
 
----  
+---
 
 ### Feature Branching
 
 1. Create a new feature branch called `squash_some_bugs`
-2. Edit `bugs.rb` and remove all the bugs.
-3. Commit
-4. Push
+1. Edit `bugs.rb` and remove all the bugs.
+1. Commit
+1. Push
 
 ---
 
@@ -250,16 +250,17 @@ git push origin squash_some_bugs
 ---
 
 ### Example Plan
+
 1. Checkout a new branch and edit conflicts.rb. Add 'Line4' and 'Line5'.
-2. Commit and push
-3. Checkout master and edit conflicts.rb. Add 'Line6' and 'Line7' below 'Line3'.
-4. Commit and push to master
-5. Create a merge request and watch it fail
-6. Rebase our new branch with master
-7. Fix conflicts on the conflicts.rb file.
-8. Stage the file and continue rebasing
-9. Force push the changes
-10. Finally continue with the Merge Request
+1. Commit and push
+1. Checkout master and edit conflicts.rb. Add 'Line6' and 'Line7' below 'Line3'.
+1. Commit and push to master
+1. Create a merge request and watch it fail
+1. Rebase our new branch with master
+1. Fix conflicts on the conflicts.rb file.
+1. Stage the file and continue rebasing
+1. Force push the changes
+1. Finally continue with the Merge Request
 
 ---
 
@@ -362,15 +363,15 @@ Don't reset after pushing
 ### Reset Workflow
 
 1. Edit file again 'edit_this_file.rb'
-2. Check status
-3. Add and commit with wrong message
-4. Check log
-5. Amend commit
-6. Check log
-7. Soft reset
-8. Check log
-9. Pull for updates
-10. Push changes
+1. Check status
+1. Add and commit with wrong message
+1. Check log
+1. Amend commit
+1. Check log
+1. Soft reset
+1. Check log
+1. Pull for updates
+1. Push changes
 
 ----
 
@@ -389,9 +390,9 @@ Don't reset after pushing
 
 ### Note
 
-git revert vs git reset  
-Reset removes the commit while revert removes the changes but leaves the commit  
-Revert is safer considering we can revert a revert  
+git revert vs git reset
+Reset removes the commit while revert removes the changes but leaves the commit
+Revert is safer considering we can revert a revert
 
 
     # Changed file
diff --git a/doc/university/training/topics/bisect.md b/doc/university/training/topics/bisect.md
index 01e93e4dcb0c65c839773f518e7c8e6cf2ed1c83..4848d0412c125ce0af34926549d723951af0868a 100644
--- a/doc/university/training/topics/bisect.md
+++ b/doc/university/training/topics/bisect.md
@@ -2,7 +2,7 @@
 comments: false
 ---
 
-# Bisect	  	
+# Bisect
 
 ----------
 
@@ -17,11 +17,11 @@ comments: false
 ## Bisect
 
 1. Start the bisect process
-2. Enter the bad revision (usually latest commit)
-3. Enter a known good revision (commit/branch)
-4. Run code to see if bug still exists
-5. Tell bisect the result
-6. Repeat the previous 2 items until you find the offending commit
+1. Enter the bad revision (usually latest commit)
+1. Enter a known good revision (commit/branch)
+1. Run code to see if bug still exists
+1. Tell bisect the result
+1. Repeat the previous 2 items until you find the offending commit
 
 ----------
 
diff --git a/doc/university/training/topics/getting_started.md b/doc/university/training/topics/getting_started.md
index 1441e4b89b2023bd9cffd6b89f476a943fb4b368..66cb08feacb17db658ba6ec1250d307c244102ef 100644
--- a/doc/university/training/topics/getting_started.md
+++ b/doc/university/training/topics/getting_started.md
@@ -35,11 +35,10 @@ comments: false
 
 ## Instantiate workflow with clone
 
-1. Create a project in your user namespace
-   - Choose to import from 'Any Repo by URL' and use
-     https://gitlab.com/gitlab-org/training-examples.git
-2. Create a '`Workspace`' directory in your home directory.
-3. Clone the '`training-examples`' project
+1. Create a project in your user namespace.
+  - Choose to import from 'Any Repo by URL' and use <https://gitlab.com/gitlab-org/training-examples.git>.
+1. Create a '`Workspace`' directory in your home directory.
+1. Clone the '`training-examples`' project.
 
 ----------
 
diff --git a/doc/university/training/topics/git_log.md b/doc/university/training/topics/git_log.md
index 3e39ea5cc9ab65b627b3bcb40e2f0d36b3b98377..6ba6f9eb69d9da01445048d24be9b117e6c8e95b 100644
--- a/doc/university/training/topics/git_log.md
+++ b/doc/university/training/topics/git_log.md
@@ -46,11 +46,11 @@ Git log lists commit history. It allows searching and filtering.
 ## Git Log Workflow
 
 1. Change to workspace directory
-2. Clone the multi runner projects
-3. Change to project dir
-4. Search by author
-5. Search by date
-6. Combine
+1. Clone the multi runner projects
+1. Change to project dir
+1. Search by author
+1. Search by date
+1. Combine
 
 ----------
 
diff --git a/doc/university/training/topics/merge_conflicts.md b/doc/university/training/topics/merge_conflicts.md
index 9a1ce55086804b67a1c115651d2a8a0a810f32f3..071baddf508f9673ff931a80cf9a641d8ea6d580 100644
--- a/doc/university/training/topics/merge_conflicts.md
+++ b/doc/university/training/topics/merge_conflicts.md
@@ -16,15 +16,15 @@ comments: false
 ## Merge conflicts
 
 1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
-2. Commit and push
-3. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
-4. Commit and push to master
-5. Create a merge request and watch it fail
-6. Rebase our new branch with master
-7. Fix conflicts on the `conflicts.rb` file.
-8. Stage the file and continue rebasing
-9. Force push the changes
-10. Finally continue with the Merge Request
+1. Commit and push.
+1. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
+1. Commit and push to master.
+1. Create a merge request and watch it fail.
+1. Rebase our new branch with master.
+1. Fix conflicts on the `conflicts.rb` file.
+1. Stage the file and continue rebasing.
+1. Force push the changes.
+1. Finally continue with the Merge Request.
 
 ----------
 
diff --git a/doc/university/training/topics/rollback_commits.md b/doc/university/training/topics/rollback_commits.md
index 11cb557651f8ce9e56dfd9c941dd33d6d5c29860..44304634f36bf477674dc1141f226f18090496ab 100644
--- a/doc/university/training/topics/rollback_commits.md
+++ b/doc/university/training/topics/rollback_commits.md
@@ -41,15 +41,15 @@ comments: false
 ## Reset Workflow
 
 1. Edit file again 'edit_this_file.rb'
-2. Check status
-3. Add and commit with wrong message
-4. Check log
-5. Amend commit
-6. Check log
-7. Soft reset
-8. Check log
-9. Pull for updates
-10. Push changes
+1. Check status
+1. Add and commit with wrong message
+1. Check log
+1. Amend commit
+1. Check log
+1. Soft reset
+1. Check log
+1. Pull for updates
+1. Push changes
 
 
 ----------
diff --git a/doc/university/training/topics/stash.md b/doc/university/training/topics/stash.md
index 315ced1a19600a4cb4b2ea39c6c10a94b480703a..42eedea14e53a5d405b9d8d4c899d525e6a27c1b 100644
--- a/doc/university/training/topics/stash.md
+++ b/doc/university/training/topics/stash.md
@@ -66,12 +66,12 @@ stashes.
 ## Git Stash
 
 1. Modify a file
-2. Stage file
-3. Stash it
-4. View our stash list
-5. Confirm no pending changes through status
-5. Apply with pop
-6. View list to confirm changes
+1. Stage file
+1. Stash it
+1. View our stash list
+1. Confirm no pending changes through status
+1. Apply with pop
+1. View list to confirm changes
 
 ----------
 
diff --git a/doc/update/README.md b/doc/update/README.md
index 7d3c4c310a498a57e92e198f9e9747fefe48f657..d4fc0cc91bf7444fd7b7389bb1e528382bf35ef9 100644
--- a/doc/update/README.md
+++ b/doc/update/README.md
@@ -38,12 +38,12 @@ Starting with GitLab 9.1.0 it's possible to upgrade to a newer major, minor, or
 patch version of GitLab without having to take your GitLab instance offline.
 However, for this to work there are the following requirements:
 
-1. You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
+- You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
    9.3.
-2. You have to use [post-deployment
+- You have to use [post-deployment
    migrations](../development/post_deployment_migrations.md) (included in
-   zero downtime update steps below)
-3. You are using PostgreSQL. If you are using MySQL please look at the release
+   zero downtime update steps below).
+- You are using PostgreSQL. If you are using MySQL please look at the release
    post to see if downtime is required.
 
 Most of the time you can safely upgrade from a patch release to the next minor
diff --git a/doc/user/admin_area/settings/continuous_integration.md b/doc/user/admin_area/settings/continuous_integration.md
index 6025a5bbcdac6766ba726b01b5e7bf74f0b28826..d4853a5842e9109663cce37b64a3628d391af61e 100644
--- a/doc/user/admin_area/settings/continuous_integration.md
+++ b/doc/user/admin_area/settings/continuous_integration.md
@@ -49,3 +49,19 @@ and the default value is `30 days`. On GitLab.com they
 This setting is set per job and can be overridden in
 [`.gitlab-ci.yml`](../../../ci/yaml/README.md#artifacts-expire_in).
 To disable the expiration, set it to `0`. The default unit is in seconds.
+
+## Archive jobs **[CORE ONLY]**
+
+Archiving jobs is useful for reducing the CI/CD footprint on the system by
+removing some of the capabilities of the jobs (metadata needed to run the job),
+but persisting the traces and artifacts for auditing purposes.
+
+To set the duration for which the jobs will be considered as old and expired:
+
+1. Go to **Admin area > Settings > CI/CD > Continuous Integration and Deployment**.
+1. Change the value of "Archive jobs".
+1. Hit **Save changes** for the changes to take effect.
+
+Once that time passes, the jobs will be archived and no longer able to be
+retried. Make it empty to never expire jobs. It has to be no less than 1 day,
+for example: <code>15 days</code>, <code>1 month</code>, <code>2 years</code>.
diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md
index 64219737d6186397d6380ec25a59a142657cddc1..76f7e869ff7d88455a130d4a8dc250d3bb7828d2 100644
--- a/doc/user/profile/account/two_factor_authentication.md
+++ b/doc/user/profile/account/two_factor_authentication.md
@@ -158,7 +158,7 @@ authentication. If an SSH key is added to your GitLab account, you can generate
 a new set of recovery codes with SSH.
 
 1. Run `ssh git@gitlab.example.com 2fa_recovery_codes`.
-2. You are prompted to confirm that you want to generate new codes. Continuing this process invalidates previously saved codes.
+1. You are prompted to confirm that you want to generate new codes. Continuing this process invalidates previously saved codes.
     ```
     bash
     $ ssh git@gitlab.example.com 2fa_recovery_codes
@@ -185,7 +185,7 @@ a new set of recovery codes with SSH.
     so you do not lose access to your account again.
     ```
 
-3. Go to the GitLab sign-in page and enter your username/email and password.
+1. Go to the GitLab sign-in page and enter your username/email and password.
    When prompted for a two-factor code, enter one of the recovery codes obtained
    from the command-line output.
 
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index da7c30b6b39e36f7a731bde426c8d405f2409a87..2f989a26725883e18148d4066e22abaf00e17926 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -97,13 +97,13 @@ You and GitLab admins can see your the abovementioned information on your profil
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/14078) in GitLab 11.3.
 
-Enabling private contributions will include contributions to private projects, in the user contribution calendar graph and user recent activity. 
+Enabling private contributions will include contributions to private projects, in the user contribution calendar graph and user recent activity.
 
 To enable private contributions:
 
 1. Navigate to your personal [profile settings](#profile-settings).
-2. Check the "Private contributions" option.
-3. Hit **Update profile settings**.
+1. Check the "Private contributions" option.
+1. Hit **Update profile settings**.
 
 ## Current status
 
diff --git a/doc/user/project/clusters/eks_and_gitlab/img/rbac.png b/doc/user/project/clusters/eks_and_gitlab/img/rbac.png
new file mode 100644
index 0000000000000000000000000000000000000000..c8adaad13c2bb3d0ffa88261925df63fbb8f5dec
Binary files /dev/null and b/doc/user/project/clusters/eks_and_gitlab/img/rbac.png differ
diff --git a/doc/user/project/clusters/eks_and_gitlab/index.md b/doc/user/project/clusters/eks_and_gitlab/index.md
index ef19b05fb9e37ee69f4070c183e59253ada1917e..45d77e075f13936cfcdcc56b9e80cb4015b8d702 100644
--- a/doc/user/project/clusters/eks_and_gitlab/index.md
+++ b/doc/user/project/clusters/eks_and_gitlab/index.md
@@ -1,16 +1,8 @@
----
-author: Joshua Lambert
-author_gitlab: joshlambert
-level: intermediate
-article_type: tutorial
-date: 2018-06-05
----
-
 # Connecting and deploying to an Amazon EKS cluster
 
 ## Introduction
 
-In this tutorial, we will show how easy it is to integrate an [Amazon EKS](https://aws.amazon.com/eks/) cluster with GitLab, and begin deploying applications.
+In this tutorial, we will show how to integrate an [Amazon EKS](https://aws.amazon.com/eks/) cluster with GitLab, and begin deploying applications.
 
 For an end-to-end walkthrough we will:
 
@@ -21,7 +13,7 @@ For an end-to-end walkthrough we will:
 You will need:
 
 1. An account on GitLab, like [GitLab.com](https://gitlab.com)
-1. An Amazon EKS cluster
+1. An Amazon EKS cluster (with worker nodes properly configured)
 1. `kubectl` [installed and configured for access to the EKS cluster](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#get-started-kubectl)
 
 If you don't have an Amazon EKS cluster, one can be created by following [the EKS getting started guide](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html).
@@ -38,26 +30,103 @@ Give the project a name, and then select `Create project`.
 
 ![Create Project](img/create_project.png)
 
-## Connecting the EKS cluster
+## Configuring and connecting the EKS cluster
 
 From the left side bar, hover over `Operations` and select `Kubernetes`, then click on `Add Kubernetes cluster`, and finally `Add an existing Kubernetes cluster`.
 
 A few details from the EKS cluster will be required to connect it to GitLab.
 
-1. A valid Kubernetes certificate and token are needed to authenticate to the EKS cluster. A pair is created by default, which can be used. Open a shell and use `kubectl` to retrieve them:
-   * List the secrets with `kubectl get secrets`, and one should named similar to `default-token-xxxxx`. Copy that token name for use below.
-   * Get the certificate with `kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 -D`
-   * Retrieve the token with `kubectl get secret <secret name> -o jsonpath="{['data']['token']}" | base64 -D`.
+1. **Retrieve the certificate**: A valid Kubernetes certificate is needed to authenticate to the EKS cluster. We will use the certificate created by default. Open a shell and use `kubectl` to retrieve it:
+   - List the secrets with `kubectl get secrets`, and one should named similar to `default-token-xxxxx`. Copy that token name for use below.
+   - Get the certificate with `kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 -D`
+
+1. **Create admin token**: A `cluster-admin` token is required to install and manage Helm Tiller. GitLab establishes mutual SSL auth with Helm Tiller and creates limited service accounts for each application. To create the token we will create an admin service account as follows:
+
+   1. Create a file called `eks-admin-service-account.yaml` with the text below:
+
+      ```yaml
+      apiVersion: v1
+      kind: ServiceAccount
+      metadata:
+        name: eks-admin
+        namespace: kube-system
+      ```
+
+    2. Apply the service account to your cluster:
+
+      ```bash
+      kubectl apply -f eks-admin-service-account.yaml
+      ```
+
+      Output:
+
+      ```bash
+      serviceaccount "eks-admin" created
+      ```
+
+    3. Create a file called `eks-admin-cluster-role-binding.yaml` with the text below:
+
+      ```yaml
+      apiVersion: rbac.authorization.k8s.io/v1beta1
+      kind: ClusterRoleBinding
+      metadata:
+        name: eks-admin
+      roleRef:
+        apiGroup: rbac.authorization.k8s.io
+        kind: ClusterRole
+        name: cluster-admin
+      subjects:
+      - kind: ServiceAccount
+        name: eks-admin
+        namespace: kube-system
+      ```
+
+    4. Apply the cluster role binding to your cluster:
+
+      ```bash
+      kubectl apply -f eks-admin-cluster-role-binding.yaml
+      ```
+
+      Output:
+
+      ```bash
+      clusterrolebinding "eks-admin" created
+      ```
+
+    5. Retrieve the token for the `eks-admin` service account. Copy the `<authentication_token>` value from the output.
+
+      ```bash
+      kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
+      ```
+
+      Output:
+      
+      ```yaml
+       Name:         eks-admin-token-b5zv4
+       Namespace:    kube-system
+       Labels:       <none>
+       Annotations:  kubernetes.io/service-account.name=eks-admin
+                     kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
+
+       Type:  kubernetes.io/service-account-token
+
+       Data
+       ====
+       ca.crt:     1025 bytes
+       namespace:  11 bytes
+       token:      <authentication_token>
+       ```
+
 1. The API server endpoint is also required, so GitLab can connect to the cluster. This is displayed on the AWS EKS console, when viewing the EKS cluster details.
 
 You now have all the information needed to connect the EKS cluster:
 
-* Kubernetes cluster name: Provide a name for the cluster to identify it within GitLab.
-* Environment scope: Leave this as `*` for now, since we are only connecting a single cluster.
-* API URL: Paste in the API server endpoint retrieved above.
-* CA Certificate: Paste the certificate data from the earlier step, as-is.
-* Paste the token value.
-* Project namespace: This can be left blank to accept the default namespace, based on the project name.
+- Kubernetes cluster name: Provide a name for the cluster to identify it within GitLab.
+- Environment scope: Leave this as `*` for now, since we are only connecting a single cluster.
+- API URL: Paste in the API server endpoint retrieved above.
+- CA Certificate: Paste the certificate data from the earlier step, as-is.
+- Paste the admin token value.
+- Project namespace: This can be left blank to accept the default namespace, based on the project name.
 
 ![Add Cluster](img/add_cluster.png)
 
@@ -65,9 +134,11 @@ Click on `Add Kubernetes cluster`, the cluster is now connected to GitLab. At th
 
 If you would like to utilize your own CI/CD scripts to deploy to the cluster, you can stop here.
 
-## Disable Role-Based Access Control (RBAC)
+## Disable Role-Based Access Control (RBAC) - Optional
+
+When connecting a cluster via GitLab integration, you may specify whether the cluster is RBAC-enabled or not. This will affect how GitLab interacts with the cluster for certain operations. If you **did not** check the "RBAC-enabled cluster" checkbox at creation time, GitLab will assume RBAC is disabled for your cluster when interacting with it. If so, you must disable RBAC on your cluster for the integration to work properly.
 
-Presently, Auto DevOps and one-click app installs do not support [Kubernetes role-based access control](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). Support is [being worked on](https://gitlab.com/groups/gitlab-org/-/epics/136), but in the interim RBAC must be disabled to utilize for these features.
+![rbac](img/rbac.png)
 
 > **Note**: Disabling RBAC means that any application running in the cluster, or user who can authenticate to the cluster, has full API access. This is a [security concern](https://docs.gitlab.com/ee/user/project/clusters/#security-implications), and may not be desirable.
 
diff --git a/doc/user/project/container_registry.md b/doc/user/project/container_registry.md
index 1b1827a2658385e736ee37d40fc0099f523799f8..cac64fc0cb6d044f3605d6d53021633af0b7ad12 100644
--- a/doc/user/project/container_registry.md
+++ b/doc/user/project/container_registry.md
@@ -139,12 +139,12 @@ docker login registry.example.com -u <username> -p <token>
 1. Check to make sure that the system clock on your Docker client and GitLab server have
    been synchronized (e.g. via NTP).
 
-2. If you are using an S3-backed Registry, double check that the IAM
+1. If you are using an S3-backed Registry, double check that the IAM
    permissions and the S3 credentials (including region) are correct. See [the
    sample IAM policy](https://docs.docker.com/registry/storage-drivers/s3/)
    for more details.
 
-3. Check the Registry logs (e.g. `/var/log/gitlab/registry/current`) and the GitLab production logs
+1. Check the Registry logs (e.g. `/var/log/gitlab/registry/current`) and the GitLab production logs
    for errors (e.g. `/var/log/gitlab/gitlab-rails/production.log`). You may be able to find clues
    there.
 
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index dc73194309c754db566eb3fdc79003aeeda1f362..7688508c6acd3b16c92e42b21516ea0d520acd51 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -13,8 +13,8 @@ You can create as many deploy tokens as you like from the settings of your proje
 
 1. Log in to your GitLab account.
 1. Go to the project you want to create Deploy Tokens for.
-1. Go to **Settings** > **Repository**
-1. Click on "Expand" on **Deploy Tokens** section
+1. Go to **Settings** > **Repository**.
+1. Click on "Expand" on **Deploy Tokens** section.
 1. Choose a name and optionally an expiry date for the token.
 1. Choose the [desired scopes](#limiting-scopes-of-a-deploy-token).
 1. Click on **Create deploy token**.
@@ -46,8 +46,8 @@ the following table.
 To download a repository using a Deploy Token, you just need to:
 
 1. Create a Deploy Token with `read_repository` as a scope.
-2. Take note of your `username` and `token`
-3. `git clone` the project using the Deploy Token:
+1. Take note of your `username` and `token`.
+1. `git clone` the project using the Deploy Token:
 
     ```sh
     git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
@@ -60,8 +60,8 @@ Replace `<username>` and `<deploy_token>` with the proper values.
 To read the container registry images, you'll need to:
 
 1. Create a Deploy Token with `read_registry` as a scope.
-2. Take note of your `username` and `token`
-3. Log in to GitLab’s Container Registry using the deploy token:
+1. Take note of your `username` and `token`.
+1. Log in to GitLab’s Container Registry using the deploy token:
 
 ```sh
 docker login registry.example.com -u <username> -p <deploy_token>
diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md
index fcd6192e82f9295469d7615a0761e8689e9b21c2..3e4be04319944876c0a416ee4f8bb1d1ff09c945 100644
--- a/doc/user/project/import/github.md
+++ b/doc/user/project/import/github.md
@@ -65,9 +65,9 @@ developer documentation.
 
 Before you begin, ensure that any GitHub users who you want to map to GitLab users have either:
 
-1. A GitLab account that has logged in using the GitHub icon
+- A GitLab account that has logged in using the GitHub icon
 \- or -
-2. A GitLab account with an email address that matches the [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) of the GitHub user
+- A GitLab account with an email address that matches the [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) of the GitHub user
 
 User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with
 the user account that is performing the import.
@@ -77,10 +77,10 @@ If you are using a self-hosted GitLab instance, this process requires that you h
 [GitHub integration][gh-import].
 
 1. From the top navigation bar, click **+** and select **New project**.
-2. Select the **Import project** tab and then select **GitHub**.
-3. Select the first button to **List your GitHub repositories**. You are redirected to a page on github.com to authorize the GitLab application.
-4. Click **Authorize gitlabhq**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed.
-5. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import).
+1. Select the **Import project** tab and then select **GitHub**.
+1. Select the first button to **List your GitHub repositories**. You are redirected to a page on github.com to authorize the GitLab application.
+1. Click **Authorize gitlabhq**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed.
+1. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import).
 
 ### Using a GitHub token
 
@@ -92,12 +92,12 @@ integration enabled, that should be the preferred method to import your reposito
 If you are not using the GitHub integration, you can still perform an authorization with GitHub to grant GitLab access your repositories:
 
 1. Go to https://github.com/settings/tokens/new
-2. Enter a token description.
-3. Select the repo scope.
-4. Click **Generate token**.
-5. Copy the token hash.
-6. Go back to GitLab and provide the token to the GitHub importer.
-7. Hit the **List Your GitHub Repositories** button and wait while GitLab reads your repositories' information.
+1. Enter a token description.
+1. Select the repo scope.
+1. Click **Generate token**.
+1. Copy the token hash.
+1. Go back to GitLab and provide the token to the GitHub importer.
+1. Hit the **List Your GitHub Repositories** button and wait while GitLab reads your repositories' information.
    Once done, you'll be taken to the importer page to select the repositories to import.
 
 ### Selecting which repositories to import
@@ -107,10 +107,10 @@ your GitHub repositories are listed.
 
 1. By default, the proposed repository namespaces match the names as they exist in GitHub, but based on your permissions,
    you can choose to edit these names before you proceed to import any of them.
-2. Select the **Import** button next to any number of repositories, or select **Import all repositories**.
-3. The **Status** column shows the import status of each repository. You can choose to leave the page open and it will
+1. Select the **Import** button next to any number of repositories, or select **Import all repositories**.
+1. The **Status** column shows the import status of each repository. You can choose to leave the page open and it will
    update in realtime or you can return to it later.
-4. Once a repository has been imported, click its GitLab path to open its GitLab URL.
+1. Once a repository has been imported, click its GitLab path to open its GitLab URL.
 
 ## Mirroring and pipeline status sharing
 
diff --git a/doc/user/project/integrations/bugzilla.md b/doc/user/project/integrations/bugzilla.md
index 671804035cc27f7f531c97f3d7d3de1f2ba4dae9..040e80d529db5819c38c8f0e2c81cc74e2f6393b 100644
--- a/doc/user/project/integrations/bugzilla.md
+++ b/doc/user/project/integrations/bugzilla.md
@@ -16,8 +16,9 @@ Once you have configured and enabled Bugzilla you'll see the Bugzilla link on th
 ## Referencing issues in Bugzilla
 
 Issues in Bugzilla can be referenced in two alternative ways:
-1. `#<ID>` where `<ID>` is a number (example `#143`).
-2. `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
+
+- `#<ID>` where `<ID>` is a number (example `#143`).
+- `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
   then followed by capital letters, numbers or underscores, and `<ID>` is
   a number (example `API_32-143`).
 
diff --git a/doc/user/project/integrations/jira_cloud_configuration.md b/doc/user/project/integrations/jira_cloud_configuration.md
index 2e6e8278e6413f1e46d333ec69edd2f2dc97bcc6..cae665261758db6e16b0c8506ce6bbf13b225b44 100644
--- a/doc/user/project/integrations/jira_cloud_configuration.md
+++ b/doc/user/project/integrations/jira_cloud_configuration.md
@@ -4,16 +4,15 @@ An API token is needed when integrating with JIRA Cloud, follow the steps
 below to create one:
 
 1. Log in to https://id.atlassian.com with your email.
-2. **Click API tokens**, then **Create API token**.
+1. **Click API tokens**, then **Create API token**.
 
 ![JIRA API token](img/jira_api_token_menu.png)
 
 ![JIRA API token](img/jira_api_token.png)
 
-3. Make sure to write down your new API token as you will need it in the next [steps](jira.md#configuring-gitlab).
+1. Make sure to write down your new API token as you will need it in the next [steps](jira.md#configuring-gitlab).
 
 NOTE: **Note**
 It is important that the user associated with this email has 'write' access to projects in JIRA.
 
 The JIRA configuration is complete. You are going to need this new created token and the email you used to log in when [configuring GitLab in the next section](jira.md#configuring-gitlab).
-
diff --git a/doc/user/project/integrations/jira_server_configuration.md b/doc/user/project/integrations/jira_server_configuration.md
index 7d84ad0b07ce701ff7db6b39a65a5eb2a43b6ce6..20036183187d5271aade038117e7a98c6aa701ce 100644
--- a/doc/user/project/integrations/jira_server_configuration.md
+++ b/doc/user/project/integrations/jira_server_configuration.md
@@ -17,17 +17,17 @@ We have split this stage in steps so it is easier to follow.
 
      ![Jira user management link](img/jira_user_management_link.png)
 
-2. The next step is to create a new user (e.g., `gitlab`) who has write access
+1. The next step is to create a new user (e.g., `gitlab`) who has write access
    to projects in Jira. Enter the user's name and a _valid_ e-mail address
    since Jira sends a verification e-mail to set up the password.
    _**Note:** Jira creates the username automatically by using the e-mail
-   prefix. You can change it later, if needed. Our integration does not support SSO (such as SAML). You will need to create 
-    an HTTP basic authentication password. You can do this by visiting the user 
+   prefix. You can change it later, if needed. Our integration does not support SSO (such as SAML). You will need to create
+    an HTTP basic authentication password. You can do this by visiting the user
     profile, looking up the username, and setting a password._
 
      ![Jira create new user](img/jira_create_new_user.png)
 
-3. Create a `gitlab-developers` group which will have write access
+1. Create a `gitlab-developers` group which will have write access
    to projects in Jira. Go to the **Groups** tab and select **Create group**.
 
      ![Jira create new user](img/jira_create_new_group.png)
@@ -36,13 +36,13 @@ We have split this stage in steps so it is easier to follow.
 
      ![Jira create new group](img/jira_create_new_group_name.png)
 
-4. To give the newly-created group 'write' access, go to
+1. To give the newly-created group 'write' access, go to
    **Application access > View configuration** and add the `gitlab-developers`
    group to Jira Core.
 
      ![Jira group access](img/jira_group_access.png)
 
-5. Add the `gitlab` user to the `gitlab-developers` group by going to
+1. Add the `gitlab` user to the `gitlab-developers` group by going to
    **Users > GitLab user > Add group** and selecting the `gitlab-developers`
    group from the dropdown menu. Notice that the group says _Access_, which is
    intended as part of this process.
diff --git a/doc/user/project/integrations/redmine.md b/doc/user/project/integrations/redmine.md
index de2cf6d46472e675bcc5bf9770ce5603902c9be5..76a2617125e4d7aac5d7c819df4fab274a6c5704 100644
--- a/doc/user/project/integrations/redmine.md
+++ b/doc/user/project/integrations/redmine.md
@@ -18,15 +18,16 @@ in the table below.
 
     ![Redmine configuration](img/redmine_configuration.png)
 
-2. To disable the internal issue tracking system in a project, navigate to the General page, expand [Permissions](../settings/index.md#sharing-and-permissions), and slide the Issues switch invalid.
+1. To disable the internal issue tracking system in a project, navigate to the General page, expand [Permissions](../settings/index.md#sharing-and-permissions), and slide the Issues switch invalid.
 
     ![Issue configuration](img/issue_configuration.png)
 
 ## Referencing issues in Redmine
 
 Issues in Redmine can be referenced in two alternative ways:
-1. `#<ID>` where `<ID>` is a number (example `#143`)
-2. `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
+
+- `#<ID>` where `<ID>` is a number (example `#143`).
+- `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
   then followed by capital letters, numbers or underscores, and `<ID>` is
   a number (example `API_32-143`).
 
diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md
index 7c63967c829481e634596a2a2d11dffffb4bac3b..4d1d95da6f0a6fb888b93f17fa14273bf255217e 100644
--- a/doc/user/project/integrations/webhooks.md
+++ b/doc/user/project/integrations/webhooks.md
@@ -338,10 +338,10 @@ payload will also include information about the target of the comment. For examp
 a comment on an issue will include the specific issue information under the `issue` key.
 Valid target types:
 
-1. `commit`
-2. `merge_request`
-3. `issue`
-4. `snippet`
+- `commit`
+- `merge_request`
+- `issue`
+- `snippet`
 
 #### Comment on commit
 
diff --git a/doc/user/project/issues/automatic_issue_closing.md b/doc/user/project/issues/automatic_issue_closing.md
index b6570c777ae260b565b8f329b991bf4fc0da7457..afb7d9ada5f7bf989f5a6ca44abcda7cee0c2560 100644
--- a/doc/user/project/issues/automatic_issue_closing.md
+++ b/doc/user/project/issues/automatic_issue_closing.md
@@ -27,10 +27,11 @@ used:
 
 Note that `%{issue_ref}` is a complex regular expression defined inside GitLab's
 source code that can match references to:
-1. a local issue (`#123`),
-2. a cross-project issue (`group/project#123`) 
-3. a link to an issue
-(`https://gitlab.example.com/group/project/issues/123`).
+
+- A local issue (`#123`).
+- A cross-project issue (`group/project#123`).
+- A link to an issue
+  (`https://gitlab.example.com/group/project/issues/123`).
 
 ---
 
diff --git a/doc/user/project/new_ci_build_permissions_model.md b/doc/user/project/new_ci_build_permissions_model.md
index 23d5b34504cf3a59c57e779397b763220d196efd..9a53036b4d1384ac090491ed61643568df060374 100644
--- a/doc/user/project/new_ci_build_permissions_model.md
+++ b/doc/user/project/new_ci_build_permissions_model.md
@@ -60,7 +60,7 @@ Let's consider the following scenario:
    hosted in private repositories and you have multiple CI jobs that make use
    of these repositories.
 
-2. You invite a new [external user][ext]. CI jobs created by that user do not
+1. You invite a new [external user][ext]. CI jobs created by that user do not
    have access to internal repositories, because the user also doesn't have the
    access from within GitLab. You as an employee have to grant explicit access
    for this user. This allows us to prevent from accidental data leakage.
diff --git a/lib/gitlab/kubernetes/helm/api.rb b/lib/gitlab/kubernetes/helm/api.rb
index e21bc5314445cb1ac3775a7ed8953b10945435cc..06841ec7b76781b5fd808fcf00e8d7b3ee8391ca 100644
--- a/lib/gitlab/kubernetes/helm/api.rb
+++ b/lib/gitlab/kubernetes/helm/api.rb
@@ -89,22 +89,14 @@ module Gitlab
         end
 
         def service_account_exists?(resource)
-          resource_exists? do
-            kubeclient.get_service_account(resource.metadata.name, resource.metadata.namespace)
-          end
+          kubeclient.get_service_account(resource.metadata.name, resource.metadata.namespace)
+        rescue ::Kubeclient::ResourceNotFoundError
+          false
         end
 
         def cluster_role_binding_exists?(resource)
-          resource_exists? do
-            kubeclient.get_cluster_role_binding(resource.metadata.name)
-          end
-        end
-
-        def resource_exists?
-          yield
-        rescue ::Kubeclient::HttpError => e
-          raise e unless e.error_code == 404
-
+          kubeclient.get_cluster_role_binding(resource.metadata.name)
+        rescue ::Kubeclient::ResourceNotFoundError
           false
         end
       end
diff --git a/lib/gitlab/kubernetes/namespace.rb b/lib/gitlab/kubernetes/namespace.rb
index e6ff6160ab9f29250359d6d9be54035569d6ac0b..783c8a24741b0b80437e18a0cfa78d8cd9ff4716 100644
--- a/lib/gitlab/kubernetes/namespace.rb
+++ b/lib/gitlab/kubernetes/namespace.rb
@@ -10,9 +10,7 @@ module Gitlab
 
       def exists?
         @client.get_namespace(name)
-      rescue ::Kubeclient::HttpError => ke
-        raise ke unless ke.error_code == 404
-
+      rescue ::Kubeclient::ResourceNotFoundError
         false
       end
 
diff --git a/qa/qa/page/merge_request/show.rb b/qa/qa/page/merge_request/show.rb
index 2e69a89e386d29f03d5ddb8591709723a2bbc42d..2fd30e15ffb06e4bbde12a17211885c2014e2813 100644
--- a/qa/qa/page/merge_request/show.rb
+++ b/qa/qa/page/merge_request/show.rb
@@ -55,6 +55,10 @@ module QA
           element :labels_block
         end
 
+        view 'app/views/projects/merge_requests/_mr_title.html.haml' do
+          element :edit_button
+        end
+
         def fast_forward_possible?
           !has_text?('Fast-forward merge is not possible')
         end
@@ -163,6 +167,10 @@ module QA
           all_elements(:discussion_reply).last.click
           fill_element :reply_input, reply_text
         end
+
+        def edit!
+          click_element :edit_button
+        end
       end
     end
   end
diff --git a/qa/qa/resource/merge_request.rb b/qa/qa/resource/merge_request.rb
index 466a7942dc610cff3021205338e1332ced0002d1..77afb3cfcbac82b11c667502e0f7795d74bd1879 100644
--- a/qa/qa/resource/merge_request.rb
+++ b/qa/qa/resource/merge_request.rb
@@ -11,7 +11,9 @@ module QA
                     :target_branch,
                     :assignee,
                     :milestone,
-                    :labels
+                    :labels,
+                    :file_name,
+                    :file_content
 
       attribute :project do
         Project.fabricate! do |resource|
@@ -35,8 +37,8 @@ module QA
           resource.branch_name = target_branch
           resource.remote_branch = source_branch
           resource.new_branch = false
-          resource.file_name = "added_file.txt"
-          resource.file_content = "File Added"
+          resource.file_name = file_name
+          resource.file_content = file_content
         end
       end
 
@@ -48,6 +50,8 @@ module QA
         @assignee = nil
         @milestone = nil
         @labels = []
+        @file_name = "added_file.txt"
+        @file_content = "File Added"
       end
 
       def fabricate!
diff --git a/scripts/review_apps/review-apps.sh b/scripts/review_apps/review-apps.sh
index b180860899a66b6b19d2247e66d5f2288f671d21..00e23f12bc01c11d3f5f7cd6d72d180c168b3173 100755
--- a/scripts/review_apps/review-apps.sh
+++ b/scripts/review_apps/review-apps.sh
@@ -179,21 +179,35 @@ function delete() {
   track="${1-stable}"
   name="$CI_ENVIRONMENT_SLUG"
 
+  if [ -z "$CI_ENVIRONMENT_SLUG" ]; then
+    echo "No release given, aborting the delete!"
+    return
+  fi
+
   if [[ "$track" != "stable" ]]; then
     name="$name-$track"
   fi
 
+  if ! deployExists "${KUBE_NAMESPACE}" "${name}"; then
+    echo "The release $name doesn't exist, aborting the cleanup!"
+    return
+  fi
+
   echo "Deleting release '$name'..."
   helm delete --purge "$name" || true
 }
 
 function cleanup() {
-  echo "Cleaning up $CI_ENVIRONMENT_SLUG..."
-  kubectl -n "$KUBE_NAMESPACE" get ingress,svc,pdb,hpa,deploy,statefulset,job,pod,secret,configmap,pvc,secret,clusterrole,clusterrolebinding,role,rolebinding,sa 2>&1 \
-    | grep "$CI_ENVIRONMENT_SLUG" \
-    | awk '{print $1}' \
-    | xargs kubectl -n "$KUBE_NAMESPACE" delete \
-    || true
+  if [ -z "$CI_ENVIRONMENT_SLUG" ]; then
+    echo "No release given, aborting the delete!"
+    return
+  fi
+
+  echo "Cleaning up '$CI_ENVIRONMENT_SLUG'..."
+  kubectl -n "$KUBE_NAMESPACE" delete \
+    ingress,svc,pdb,hpa,deploy,statefulset,job,pod,secret,configmap,pvc,secret,clusterrole,clusterrolebinding,role,rolebinding,sa \
+    -l release="$CI_ENVIRONMENT_SLUG" \
+  || true
 }
 
 function install_external_dns() {
diff --git a/spec/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer_spec.js b/spec/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer_spec.js
index 2d3e178d249f2fc6cea5b1e5ac8b59d39a2b223a..7f2e246d6564207075bb034790824ddf70b0c9a8 100644
--- a/spec/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer_spec.js
+++ b/spec/javascripts/vue_shared/components/diff_viewer/viewers/image_diff_viewer_spec.js
@@ -97,6 +97,26 @@ describe('ImageDiffViewer', () => {
     });
   });
 
+  it('renders image diff for renamed', done => {
+    vm = new Vue({
+      components: {
+        imageDiffViewer,
+      },
+      template: `
+        <image-diff-viewer diff-mode="renamed" new-path="${GREEN_BOX_IMAGE_URL}" old-path="">
+          <span slot="image-overlay" class="overlay">test</span>
+        </image-diff-viewer>
+      `,
+    }).$mount();
+
+    setTimeout(() => {
+      expect(vm.$el.querySelector('img').getAttribute('src')).toBe(GREEN_BOX_IMAGE_URL);
+      expect(vm.$el.querySelector('.overlay')).not.toBe(null);
+
+      done();
+    });
+  });
+
   describe('swipeMode', () => {
     beforeEach(done => {
       createComponent({
diff --git a/spec/lib/gitlab/kubernetes/helm/api_spec.rb b/spec/lib/gitlab/kubernetes/helm/api_spec.rb
index 9200724ed2322bae0dfd506a113ffee234d83541..a8124ced28c2d10b4b41fb81cd374071b0c47414 100644
--- a/spec/lib/gitlab/kubernetes/helm/api_spec.rb
+++ b/spec/lib/gitlab/kubernetes/helm/api_spec.rb
@@ -88,8 +88,8 @@ describe Gitlab::Kubernetes::Helm::Api do
 
         context 'service account and cluster role binding does not exist' do
           before do
-            expect(client).to receive('get_service_account').with('tiller', 'gitlab-managed-apps').and_raise(Kubeclient::HttpError.new(404, 'Not found', nil))
-            expect(client).to receive('get_cluster_role_binding').with('tiller-admin').and_raise(Kubeclient::HttpError.new(404, 'Not found', nil))
+            expect(client).to receive('get_service_account').with('tiller', 'gitlab-managed-apps').and_raise(Kubeclient::ResourceNotFoundError.new(404, 'Not found', nil))
+            expect(client).to receive('get_cluster_role_binding').with('tiller-admin').and_raise(Kubeclient::ResourceNotFoundError.new(404, 'Not found', nil))
           end
 
           it 'creates a service account, followed the cluster role binding on kubeclient' do
@@ -103,7 +103,7 @@ describe Gitlab::Kubernetes::Helm::Api do
         context 'service account already exists' do
           before do
             expect(client).to receive('get_service_account').with('tiller', 'gitlab-managed-apps').and_return(service_account_resource)
-            expect(client).to receive('get_cluster_role_binding').with('tiller-admin').and_raise(Kubeclient::HttpError.new(404, 'Not found', nil))
+            expect(client).to receive('get_cluster_role_binding').with('tiller-admin').and_raise(Kubeclient::ResourceNotFoundError.new(404, 'Not found', nil))
           end
 
           it 'updates the service account, followed by creating the cluster role binding' do
diff --git a/spec/lib/gitlab/kubernetes/namespace_spec.rb b/spec/lib/gitlab/kubernetes/namespace_spec.rb
index e098612f6fbb1d24dd168a55d1e8ad04f00924fb..e1c35c355f464bfa4f5f7aa50b3c8e64da5c45eb 100644
--- a/spec/lib/gitlab/kubernetes/namespace_spec.rb
+++ b/spec/lib/gitlab/kubernetes/namespace_spec.rb
@@ -9,7 +9,7 @@ describe Gitlab::Kubernetes::Namespace do
 
   describe '#exists?' do
     context 'when namespace do not exits' do
-      let(:exception) { ::Kubeclient::HttpError.new(404, "namespace #{name} not found", nil) }
+      let(:exception) { ::Kubeclient::ResourceNotFoundError.new(404, "namespace #{name} not found", nil) }
 
       it 'returns false' do
         expect(client).to receive(:get_namespace).with(name).once.and_raise(exception)
diff --git a/spec/services/clusters/applications/check_installation_progress_service_spec.rb b/spec/services/clusters/applications/check_installation_progress_service_spec.rb
index 1a565bb734d9a8fa0d8beca2886c8147a75744ac..ea17f2bb4230f0dcf1f6175744d9ea52411bc64c 100644
--- a/spec/services/clusters/applications/check_installation_progress_service_spec.rb
+++ b/spec/services/clusters/applications/check_installation_progress_service_spec.rb
@@ -19,6 +19,10 @@ describe Clusters::Applications::CheckInstallationProgressService do
   shared_examples 'a not yet terminated installation' do |a_phase|
     let(:phase) { a_phase }
 
+    before do
+      expect(service).to receive(:installation_phase).once.and_return(phase)
+    end
+
     context "when phase is #{a_phase}" do
       context 'when not timeouted' do
         it 'reschedule a new check' do
@@ -50,8 +54,6 @@ describe Clusters::Applications::CheckInstallationProgressService do
   end
 
   before do
-    expect(service).to receive(:installation_phase).once.and_return(phase)
-
     allow(service).to receive(:installation_errors).and_return(errors)
     allow(service).to receive(:remove_installation_pod).and_return(nil)
   end
@@ -60,6 +62,10 @@ describe Clusters::Applications::CheckInstallationProgressService do
     context 'when installation POD succeeded' do
       let(:phase) { Gitlab::Kubernetes::Pod::SUCCEEDED }
 
+      before do
+        expect(service).to receive(:installation_phase).once.and_return(phase)
+      end
+
       it_behaves_like 'a terminated installation'
 
       it 'make the application installed' do
@@ -76,6 +82,10 @@ describe Clusters::Applications::CheckInstallationProgressService do
       let(:phase) { Gitlab::Kubernetes::Pod::FAILED }
       let(:errors) { 'test installation failed' }
 
+      before do
+        expect(service).to receive(:installation_phase).once.and_return(phase)
+      end
+
       it_behaves_like 'a terminated installation'
 
       it 'make the application errored' do
@@ -87,5 +97,22 @@ describe Clusters::Applications::CheckInstallationProgressService do
     end
 
     RESCHEDULE_PHASES.each { |phase| it_behaves_like 'a not yet terminated installation', phase }
+
+    context 'when installation raises a Kubeclient::HttpError' do
+      let(:cluster) { create(:cluster, :provided_by_user, :project) }
+
+      before do
+        application.update!(cluster: cluster)
+
+        expect(service).to receive(:installation_phase).and_raise(Kubeclient::HttpError.new(401, 'Unauthorized', nil))
+      end
+
+      it 'shows the response code from the error' do
+        service.execute
+
+        expect(application).to be_errored
+        expect(application.status_reason).to eq('Kubernetes error: 401')
+      end
+    end
   end
 end
diff --git a/spec/services/clusters/applications/install_service_spec.rb b/spec/services/clusters/applications/install_service_spec.rb
index 4bd19f5bd798717cef90a454193c78ce5deb876a..2f801d019fe09665adec7e6e8e3e6b30d3652c2f 100644
--- a/spec/services/clusters/applications/install_service_spec.rb
+++ b/spec/services/clusters/applications/install_service_spec.rb
@@ -42,7 +42,7 @@ describe Clusters::Applications::InstallService do
         service.execute
 
         expect(application).to be_errored
-        expect(application.status_reason).to match('Kubernetes error.')
+        expect(application.status_reason).to match('Kubernetes error: 500')
       end
     end
 
diff --git a/spec/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service_spec.rb b/spec/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service_spec.rb
index 4d1a6bb7b3a0c885f93a4a3f5c9fbb2e2fb36067..a5806559b140cfccf899fc1ba9d5b762c50572e0 100644
--- a/spec/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service_spec.rb
+++ b/spec/services/clusters/gcp/kubernetes/fetch_kubernetes_token_service_spec.rb
@@ -19,13 +19,16 @@ describe Clusters::Gcp::Kubernetes::FetchKubernetesTokenService do
 
     subject { described_class.new(kubeclient, service_account_token_name, namespace).execute }
 
+    before do
+      stub_kubeclient_discover(api_url)
+    end
+
     context 'when params correct' do
       let(:decoded_token) { 'xxx.token.xxx' }
       let(:token) { Base64.encode64(decoded_token) }
 
       context 'when gitlab-token exists' do
         before do
-          stub_kubeclient_discover(api_url)
           stub_kubeclient_get_secret(
             api_url,
             {
@@ -39,9 +42,17 @@ describe Clusters::Gcp::Kubernetes::FetchKubernetesTokenService do
         it { is_expected.to eq(decoded_token) }
       end
 
+      context 'when there is a 500 error' do
+        before do
+          stub_kubeclient_get_secret_error(api_url, service_account_token_name, namespace: namespace, status: 500)
+        end
+
+        it { expect { subject }.to raise_error(Kubeclient::HttpError) }
+      end
+
       context 'when gitlab-token does not exist' do
         before do
-          allow(kubeclient).to receive(:get_secret).and_raise(Kubeclient::HttpError.new(404, 'Not found', nil))
+          stub_kubeclient_get_secret_error(api_url, service_account_token_name, namespace: namespace, status: 404)
         end
 
         it { is_expected.to be_nil }
diff --git a/spec/support/helpers/kubernetes_helpers.rb b/spec/support/helpers/kubernetes_helpers.rb
index a03d9c4045f28cc423d231259ac752bb28a6fd18..35ae04b16c640f22ac599366c25b5c3a512058ad 100644
--- a/spec/support/helpers/kubernetes_helpers.rb
+++ b/spec/support/helpers/kubernetes_helpers.rb
@@ -41,9 +41,9 @@ module KubernetesHelpers
       .to_return(kube_response(kube_v1_secret_body(options)))
   end
 
-  def stub_kubeclient_get_secret_error(api_url, name, namespace: 'default')
+  def stub_kubeclient_get_secret_error(api_url, name, namespace: 'default', status: 404)
     WebMock.stub_request(:get, api_url + "/api/v1/namespaces/#{namespace}/secrets/#{name}")
-      .to_return(status: [404, "Internal Server Error"])
+      .to_return(status: [status, "Internal Server Error"])
   end
 
   def stub_kubeclient_create_service_account(api_url, namespace: 'default')