Merge commit '26bff00d64d026ca99fbe348c239dc8060c00743' into 11-9-stable

33 files changed, 159 insertions, 135 deletions

diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md
index d5d0d99ac24..440c2b1285a 100644
--- a/doc/administration/auth/ldap.md
+++ b/doc/administration/auth/ldap.md
@@ -81,6 +81,9 @@ library. `tls` corresponds to StartTLS, not to be confused with regular TLS.
 Normally, if you specify `ssl` it will be on port 636, while `tls` (StartTLS)
 would be on port 389. `plain` also operates on port 389.
 
+NOTE: **Note:**
+LDAP users must have an email address set, regardless of whether it is used to log in.
+
 **Omnibus configuration**
 
 ```ruby
@@ -136,14 +139,54 @@ main:
   ##
   verify_certificates: true
 
-  ##
-  ## Specifies the SSL version for OpenSSL to use, if the OpenSSL default
-  ## is not appropriate.
-  ##
-  ##   Example: 'TLSv1_1'
-  ##
-  ##
-  ssl_version: ''
+  # OpenSSL::SSL::SSLContext options.
+  tls_options:
+    # Specifies the path to a file containing a PEM-format CA certificate,
+    # e.g. if you need to use an internal CA.
+    #
+    #   Example: '/etc/ca.pem'
+    #
+    ca_file: ''
+
+    # Specifies the SSL version for OpenSSL to use, if the OpenSSL default
+    # is not appropriate.
+    #
+    #   Example: 'TLSv1_1'
+    #
+    ssl_version: ''
+
+    # Specific SSL ciphers to use in communication with LDAP servers.
+    #
+    # Example: 'ALL:!EXPORT:!LOW:!aNULL:!eNULL:!SSLv2'
+    ciphers: ''
+
+    # Client certificate
+    #
+    # Example:
+    #   cert: |
+    #     -----BEGIN CERTIFICATE-----
+    #     MIIDbDCCAlSgAwIBAgIGAWkJxLmKMA0GCSqGSIb3DQEBCwUAMHcxFDASBgNVBAoTC0dvb2dsZSBJ
+    #     bmMuMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MRQwEgYDVQQDEwtMREFQIENsaWVudDEPMA0GA1UE
+    #     CxMGR1N1aXRlMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTAeFw0xOTAyMjAwNzE4
+    #     rntnF4d+0dd7zP3jrWkbdtoqjLDT/5D7NYRmVCD5vizV98FJ5//PIHbD1gL3a9b2MPAc6k7NV8tl
+    #     ...
+    #     4SbuJPAiJxC1LQ0t39dR6oMCAMab3hXQqhL56LrR6cRBp6Mtlphv7alu9xb/x51y2x+g2zWtsf80
+    #     Jrv/vKMsIh/sAyuogb7hqMtp55ecnKxceg==
+    #     -----END CERTIFICATE -----
+    cert: ''
+
+    # Client private key
+    #   key: |
+    #     -----BEGIN PRIVATE KEY-----
+    #     MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC3DmJtLRmJGY4xU1QtI3yjvxO6
+    #     bNuyE4z1NF6Xn7VSbcAaQtavWQ6GZi5uukMo+W5DHVtEkgDwh92ySZMuJdJogFbNvJvHAayheCdN
+    #     7mCQ2UUT9jGXIbmksUn9QMeJVXTZjgJWJzPXToeUdinx9G7+lpVa62UATEd1gaI3oyL72WmpDy/C
+    #     rntnF4d+0dd7zP3jrWkbdtoqjLDT/5D7NYRmVCD5vizV98FJ5//PIHbD1gL3a9b2MPAc6k7NV8tl
+    #     ...
+    #     +9IhSYX+XIg7BZOVDeYqlPfxRvQh8vy3qjt/KUihmEPioAjLaGiihs1Fk5ctLk9A2hIUyP+sEQv9
+    #     l6RG+a/mW+0rCWn8JAd464Ps9hE=
+    #     -----END PRIVATE KEY-----
+    key: ''
 
   ##
   ## Set a timeout, in seconds, for LDAP queries. This helps avoid blocking
diff --git a/doc/articles/index.md b/doc/articles/index.md
index 87ee17bb6de..162db11d6ac 100644
--- a/doc/articles/index.md
+++ b/doc/articles/index.md
@@ -4,8 +4,8 @@ comments: false
 
 # Technical articles list (deprecated)
 
-[Technical articles](../development/documentation/index.md#technical-articles) are
-topic-related documentation, written with an user-friendly approach and language, aiming
+Technical articles are
+topic-related documentation, written with a user-friendly approach and language, aiming
 to provide the community with guidance on specific processes to achieve certain objectives.
 
 The list of technical articles was [deprecated](https://gitlab.com/gitlab-org/gitlab-ce/issues/41138) in favor of having them linked from their topic-related documentation:
diff --git a/doc/ci/variables/README.md b/doc/ci/variables/README.md
index 6fe352df48a..08db89124de 100644
--- a/doc/ci/variables/README.md
+++ b/doc/ci/variables/README.md
@@ -79,19 +79,23 @@ future GitLab releases.**
 | **CI_JOB_STAGE**                          | 9.0    | 0.5    | The name of the stage as defined in `.gitlab-ci.yml` |
 | **CI_JOB_TOKEN**                          | 9.0    | 1.2    | Token used for authenticating with the [GitLab Container Registry][registry] and downloading [dependent repositories][dependent-repositories] |
 | **CI_JOB_URL**                            | 11.1   | 0.5    | Job details URL |
-| **CI_MERGE_REQUEST_ID**                   | 11.6   | all    | The ID of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_IID**                  | 11.6   | all    | The IID of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_PROJECT_ID**           | 11.6   | all    | The ID of the project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_PROJECT_PATH**         | 11.6   | all    | The path of the project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) (e.g. `namespace/awesome-project`) |
-| **CI_MERGE_REQUEST_PROJECT_URL**          | 11.6   | all    | The URL of the project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`) |
-| **CI_MERGE_REQUEST_REF_PATH**             | 11.6   | all    | The ref path of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`) |
-| **CI_MERGE_REQUEST_SOURCE_BRANCH_NAME**   | 11.6   | all    | The source branch name of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_SOURCE_BRANCH_SHA**    | 11.9   | all    | The HEAD sha of the source branch of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_SOURCE_PROJECT_ID**    | 11.6   | all    | The ID of the source project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_SOURCE_PROJECT_PATH**  | 11.6   | all    | The path of the source project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_SOURCE_PROJECT_URL**   | 11.6   | all    | The URL of the source project of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_TARGET_BRANCH_NAME**   | 11.6   | all    | The target branch name of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
-| **CI_MERGE_REQUEST_TARGET_BRANCH_SHA**    | 11.9   | all    | The HEAD sha of the target branch of the merge request if it's [pipelines for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_ID**                   | 11.6   | all    | The ID of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_IID**                  | 11.6   | all    | The IID of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_PROJECT_ID**           | 11.6   | all    | The ID of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_PROJECT_PATH**         | 11.6   | all    | The path of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `namespace/awesome-project`) |
+| **CI_MERGE_REQUEST_PROJECT_URL**          | 11.6   | all    | The URL of the project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) (e.g. `http://192.168.10.15:3000/namespace/awesome-project`) |
+| **CI_MERGE_REQUEST_REF_PATH**             | 11.6   | all    | The ref path of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). (e.g. `refs/merge-requests/1/head`) |
+| **CI_MERGE_REQUEST_SOURCE_BRANCH_NAME**   | 11.6   | all    | The source branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_SOURCE_BRANCH_SHA**    | 11.9   | all    | The HEAD sha of the source branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_SOURCE_PROJECT_ID**    | 11.6   | all    | The ID of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_SOURCE_PROJECT_PATH**  | 11.6   | all    | The path of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_SOURCE_PROJECT_URL**   | 11.6   | all    | The URL of the source project of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_TARGET_BRANCH_NAME**   | 11.6   | all    | The target branch name of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_TARGET_BRANCH_SHA**    | 11.9   | all    | The HEAD sha of the target branch of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_TITLE**                | 11.9   | all    | The title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_ASSIGNEES**            | 11.9   | all    | Comma-separated usernames of the assignees of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md). **Comming soon**: [Multitle assignees for merge requests](https://gitlab.com/gitlab-org/gitlab-ee/issues/2004) |
+| **CI_MERGE_REQUEST_MILESTONE**            | 11.9   | all    | The milestone title of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
+| **CI_MERGE_REQUEST_LABELS**               | 11.9   | all    | Comma-separated label names of the merge request if [the pipelines are for merge requests](../merge_request_pipelines/index.md) |
 | **CI_NODE_INDEX**                         | 11.5   | all    | Index of the job in the job set. If the job is not parallelized, this variable is not set. |
 | **CI_NODE_TOTAL**                         | 11.5   | all    | Total number of instances of this job running in parallel. If the job is not parallelized, this variable is set to `1`. |
 | **CI_API_V4_URL**                         | 11.7   | all    | The GitLab API v4 root URL |
diff --git a/doc/development/changelog.md b/doc/development/changelog.md
index cd0a1f46d27..6efed36edf0 100644
--- a/doc/development/changelog.md
+++ b/doc/development/changelog.md
@@ -135,21 +135,13 @@ If you're working on the GitLab EE repository, the entry will be added to
 
 | Argument            | Shorthand | Purpose                                                                                                                                 |
 | -----------------   | --------- | --------------------------------------------------------------------------------------------------------------------------------------- |
-| [`--amend`]         |           | Amend the previous commit                                                                                                               |
-| [`--force`]         | `-f`      | Overwrite an existing entry                                                                                                             |
-| [`--merge-request`] | `-m`      | Set merge request ID                                                                                                                    |
-| [`--dry-run`]       | `-n`      | Don't actually write anything, just print                                                                                               |
-| [`--git-username`]  | `-u`      | Use Git user.name configuration as the author                                                                                           |
-| [`--type`]          | `-t`      | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` |
-| [`--help`]          | `-h`      | Print help message                                                                                                                      |
-
-[`--amend`]: #-amend
-[`--force`]: #-force-or-f
-[`--merge-request`]: #-merge-request-or-m
-[`--dry-run`]: #-dry-run-or-n
-[`--git-username`]: #-git-username-or-u
-[`--type`]: #-type-or-t
-[`--help`]: #-help
+| [`--amend`](#--amend)         |           | Amend the previous commit                                                                                                               |
+| [`--force`](#--force-or--f)         | `-f`      | Overwrite an existing entry                                                                                                             |
+| [`--merge-request`](#--merge-request-or--m) | `-m`      | Set merge request ID                                                                                                                    |
+| [`--dry-run`](#--dry-run-or--n)       | `-n`      | Don't actually write anything, just print                                                                                               |
+| [`--git-username`](#--git-username-or--u)  | `-u`      | Use Git user.name configuration as the author                                                                                           |
+| [`--type`](#--type-or--t)          | `-t`      | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` |
+| `--help`          | `-h`      | Print help message                                                                                                                      |
 
 ##### `--amend`
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index 4e766f37871..8b14c3b20ea 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -179,7 +179,7 @@ the feature you contribute through all of these steps.
 1. Added to [the website](https://gitlab.com/gitlab-com/www-gitlab-com/), if relevant
 1. Community questions answered
 1. Answers to questions radiated (in docs/wiki/support etc.)
-1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-or-end-to-end-tests) added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams) with any questions
+1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-at-the-system-level-aka-end-to-end-tests) added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams) with any questions
 
 If you add a dependency in GitLab (such as an operating system package) please
 consider updating the following and note the applicability of each in your
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 652fe3ea711..a4da34a50ce 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -511,10 +511,10 @@ Currently, the following tests are in place:
 
 1. `docs lint`: Check that all internal (relative) links work correctly and
    that all cURL examples in API docs use the full switches. It's recommended
-   to [check locally](#previewing-locally) before pushing to GitLab by executing the command
+   to [check locally](#previewing-the-changes-live) before pushing to GitLab by executing the command
    `bundle exec nanoc check internal_links` on your local
    [`gitlab-docs`](https://gitlab.com/gitlab-com/gitlab-docs) directory.
-1. [`ee_compat_check`](../automatic_ce_ee_merge.md#avoiding-ce-gt-ee-merge-conflicts-beforehand) (runs on CE only):
+1. [`ee_compat_check`](../automatic_ce_ee_merge.md#avoiding-ce-ee-merge-conflicts-beforehand) (runs on CE only):
     When you submit a merge request to GitLab Community Edition (CE),
     there is this additional job that runs against Enterprise Edition (EE)
     and checks if your changes can apply cleanly to the EE codebase.
diff --git a/doc/development/documentation/site_architecture/global_nav.md b/doc/development/documentation/site_architecture/global_nav.md
index 0aa3c41a225..f2f4f5f0e1c 100644
--- a/doc/development/documentation/site_architecture/global_nav.md
+++ b/doc/development/documentation/site_architecture/global_nav.md
@@ -62,7 +62,7 @@ the consent of one of the technical writers.
 The global nav is built from two files:
 
 - [Data](#data-file)
-- [Layout](#layout-file)
+- [Layout](#layout-file-logic)
 
 The data file feeds the layout with the links to the docs. The layout organizes
 the data among the nav in containers properly [styled](#css-classes).
diff --git a/doc/development/documentation/styleguide.md b/doc/development/documentation/styleguide.md
index cd38721e3ab..0c51d3832aa 100644
--- a/doc/development/documentation/styleguide.md
+++ b/doc/development/documentation/styleguide.md
@@ -36,7 +36,7 @@ gem will support all [GFM markup](../../user/markdown.md) in the future. For now
 use regular markdown markup, following the rules on this style guide. For a complete
 Kramdown reference, check the [GitLab Markdown Kramdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
 Use Kramdown markup wisely: do not overuse its specific markup (e.g., `{:.class}`) as it will not render properly in
-[`/help`](#gitlab-help).
+[`/help`](index.md#gitlab-help).
 
 ## Content
 
@@ -630,7 +630,7 @@ In this case:
 - The code blocks are indented one or more spaces under the list item to render
   correctly.
 - Different highlighting languages are used for each config in the code block.
-- The [references](#references) guide is used for reconfigure/restart.
+- The [GitLab Restart](#gitlab-restart) section is used to explain a required restart/reconfigure of GitLab.
 
 ## API
 
diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md
index 17da4c51033..41a64044c68 100644
--- a/doc/development/ee_features.md
+++ b/doc/development/ee_features.md
@@ -161,7 +161,7 @@ still having access the class's implementation with `super`.
 
 There are a few gotchas with it:
 
-- you should always [`extend ::Gitlab::Utils::Override`] and use `override` to
+- you should always [`extend ::Gitlab::Utils::Override`](utilities.md#overridehttpsgitlabcomgitlab-orggitlab-ceblobmasterlibgitlabutilsoverriderb) and use `override` to
   guard the "overrider" method to ensure that if the method gets renamed in
   CE, the EE override won't be silently forgotten.
 - when the "overrider" would add a line in the middle of the CE
@@ -273,8 +273,6 @@ module EE
 end
 ```
 
-[`extend ::Gitlab::Utils::Override`]: utilities.md#override
-
 ##### Overriding CE class methods
 
 The same applies to class methods, except we want to use
@@ -977,7 +975,7 @@ if (renderIfEE) {
 To separate EE-specific styles in SCSS files, if a component you're adding styles for
 is limited to only EE, it is better to have a separate SCSS file in appropriate directory
 within `app/assets/stylesheets`.
-See [backporting changes](#backporting-changes) for instructions on how to merge changes safely.
+See [backporting changes](#backporting-changes-from-EE-to-CE) for instructions on how to merge changes safely.
 
 In some cases, this is not entirely possible or creating dedicated SCSS file is an overkill,
 e.g. a text style of some component is different for EE. In such cases,
diff --git a/doc/development/fe_guide/architecture.md b/doc/development/fe_guide/architecture.md
index aebb22caa15..c67389b169e 100644
--- a/doc/development/fe_guide/architecture.md
+++ b/doc/development/fe_guide/architecture.md
@@ -11,12 +11,9 @@ Architectural decisions should be accessible to everyone, so please document
 them in the relevant Merge Request discussion or by updating our documentation
 when appropriate.
 
-You can find the Frontend Architecture experts on the [team page][team-page].
+You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/team).
 
 ## Examples
 
 You can find documentation about the desired architecture for a new feature
-built with Vue.js [here][vue-section].
-
-[team-page]: https://about.gitlab.com/team
-[vue-section]: vue.md#frontend.html#how-to-build-a-new-feature-with-vue-js
+built with Vue.js [here](vue.md).
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 3cd70bd63fa..435fdf39fb4 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -122,7 +122,7 @@ Check this [page](vuex.md) for more details.
 
 ## Style guide
 
-Please refer to the Vue section of our [style guide](style_guide_js.md#vue-js)
+Please refer to the Vue section of our [style guide](style_guide_js.md#vuejs)
 for best practices while writing your Vue components and templates.
 
 ## Testing Vue Components
@@ -132,7 +132,7 @@ Each Vue component has a unique output. This output is always present in the ren
 Although we can test each method of a Vue component individually, our goal must be to test the output
 of the render/template function, which represents the state at all times.
 
-Make use of the [axios mock adapter](axios.md#mock-axios-response-on-tests) to mock data returned.
+Make use of the [axios mock adapter](axios.md#mock-axios-response-in-tests) to mock data returned.
 
 Here's how we would test the Todo App above:
 
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 2bd8332bf93..cfe0e6f70fc 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -40,7 +40,7 @@ bundle exec rspec spec/[path]/[to]/[spec].rb
   to separate phases.
 - Use `Gitlab.config.gitlab.host` rather than hard coding `'localhost'`
 - Don't assert against the absolute value of a sequence-generated attribute (see
-  [Gotchas](../gotchas.md#dont-assert-against-the-absolute-value-of-a-sequence-generated-attribute)).
+  [Gotchas](../gotchas.md#do-not-assert-against-the-absolute-value-of-a-sequence-generated-attribute)).
 - Don't supply the `:each` argument to hooks since it's the default.
 - On `before` and `after` hooks, prefer it scoped to `:context` over `:all`
 - When using `evaluate_script("$('.js-foo').testSomething()")` (or `execute_script`) which acts on a given element,
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index a7a3459719b..5d46833a1e2 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -46,7 +46,7 @@ They're useful to test permissions, redirections, what view is rendered etc.
 | `app/mailers/` | `spec/mailers/` | RSpec | |
 | `lib/api/` | `spec/requests/api/` | RSpec | |
 | `lib/ci/api/` | `spec/requests/ci/api/` | RSpec | |
-| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [JavaScript](#javascript) section. |
+| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [Karma JavaScript test suite](frontend_testing.md#karma-test-suite) section. |
 
 ### About controller tests
 
@@ -210,7 +210,7 @@ trade-off:
 - Integration tests are a bit more expensive, but don't abuse them. A system test
   is often better than an integration test that is stubbing a lot of internals.
 - System tests are expensive (compared to unit tests), even more if they require
-  a JavaScript driver. Make sure to follow the guidelines in the [Speed](#test-speed)
+  a JavaScript driver. Make sure to follow the guidelines in the [Speed](best_practices.md#test-speed)
   section.
 
 Another way to see it is to think about the "cost of tests", this is well
diff --git a/doc/user/admin_area/monitoring/health_check.md b/doc/user/admin_area/monitoring/health_check.md
index 91e2aafc682..e183898dfb1 100644
--- a/doc/user/admin_area/monitoring/health_check.md
+++ b/doc/user/admin_area/monitoring/health_check.md
@@ -1,6 +1,7 @@
 # Health Check
 
 > **Notes:**
+
 >   - Liveness and readiness probes were [introduced][ce-10416] in GitLab 9.1.
 >   - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and was
 >     be deprecated in GitLab 9.1.
@@ -15,21 +16,19 @@ traffic until the system is ready or restart the container as needed.
 
 ## IP whitelist
 
-To access monitoring resources, the client IP needs to be included in a whitelist.
+To access monitoring resources, the requesting client IP needs to be included in a whitelist.
 
 [Read how to add IPs to a whitelist for the monitoring endpoints][admin].
 
 ## Using the endpoints
 
-With default whitelist settings, the probes can be accessed from localhost:
+With default whitelist settings, the probes can be accessed from localhost using the following URLs:
 
 - `http://localhost/-/health`
 - `http://localhost/-/readiness`
 - `http://localhost/-/liveness`
 
-The first endpoint, `/-/health/`, only checks whether the application server is running. It does
--not verify the database or other services are running. A successful response will return
-a 200 status code with the following message:
+The first endpoint, `health`, only checks whether the application server is running. It does not verify the database or other services are running. A successful response will return a 200 status code with the following message:
 
 ```
 GitLab OK
@@ -37,9 +36,9 @@ GitLab OK
 
 The readiness and liveness probes will provide a report of system health in JSON format.
 
-Readiness example output:
+`readiness` probe example output:
 
-```
+```json
 {
    "queues_check" : {
       "status" : "ok"
@@ -59,9 +58,9 @@ Readiness example output:
 }
 ```
 
-Liveness example output:
+`liveness` probe example output:
 
-```
+```json
 {
    "cache_check" : {
       "status" : "ok"
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index 7422a30ff3c..8cdfb13a97b 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -56,7 +56,7 @@ group. That way you can have different clusters for different environments,
 like dev, staging, production, etc.
 
 Add another cluster similar to the first one and make sure to
-[set an environment scope](#environment-scopes) that will
+[set an environment scope](#environment-scopes-premium) that will
 differentiate the new cluster from the rest.
 
 ## Base domain
diff --git a/doc/user/group/index.md b/doc/user/group/index.md
index 300e0115c60..67b93ed6666 100644
--- a/doc/user/group/index.md
+++ b/doc/user/group/index.md
@@ -154,7 +154,7 @@ There are two different ways to add a new project to a group:
 
 ## Transfer projects into groups
 
-Learn how to [transfer a project into a group](../project/index.md#transfer-an-existing-project-into-a-group).
+Learn how to [transfer a project into a group](../project/settings/index.md#transferring-an-existing-project-into-another-namespace).
 
 ## Sharing a project with a group
 
diff --git a/doc/user/group/subgroups/index.md b/doc/user/group/subgroups/index.md
index b6f8f55978b..3cecefe11f5 100644
--- a/doc/user/group/subgroups/index.md
+++ b/doc/user/group/subgroups/index.md
@@ -1,8 +1,8 @@
 # Subgroups
 
 NOTE: **Note:**
-[Introduced][ce-2772] in GitLab 9.0. Not available when using MySQL as external
-database (support removed in GitLab 9.3 [due to performance reasons][issue]).
+[Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/2772) in GitLab 9.0. Not available when using MySQL as external
+database (support removed in GitLab 9.3 [due to performance reasons](https://gitlab.com/gitlab-org/gitlab-ce/issues/30472#note_27747600)).
 
 With subgroups (aka nested groups or hierarchical groups) you can have
 up to 20 levels of nested groups, which among other things can help you to:
@@ -13,7 +13,7 @@ up to 20 levels of nested groups, which among other things can help you to:
 - **Organize large projects.** For large projects, subgroups makes it
   potentially easier to separate permissions on parts of the source code.
 - **Make it easier to manage people and control visibility.** Give people
-  different [permissions][] depending on their group [membership](#membership).
+  different [permissions](../../permissions.md#group-members-permissions) depending on their group [membership](#membership).
 
 ## Database Requirements
 
@@ -80,9 +80,9 @@ structure.
 
 NOTE: **Note:**
 You need to be an Owner of a group in order to be able to create a subgroup. For
-more information check the [permissions table][permissions].
+more information check the [permissions table](../../permissions.md#group-members-permissions).
 For a list of words that are not allowed to be used as group names see the
-[reserved names][reserved].
+[reserved names](../../reserved_names.md).
 Users can always create subgroups if they are explicitly added as an Owner to
 a parent group even if group creation is disabled by an administrator in their
 settings.
@@ -176,6 +176,6 @@ Here's a list of what you can't do with subgroups:
   `group/subgroup01/subgroup03`.
 
 [ce-2772]: https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
-[permissions]: ../../permissions.md#group
+[permissions]: ../../permissions.md#group-members-permissions
 [reserved]:  ../../reserved_names.md
 [issue]: https://gitlab.com/gitlab-org/gitlab-ce/issues/30472#note_27747600
diff --git a/doc/user/profile/active_sessions.md b/doc/user/profile/active_sessions.md
index 5119c0e30d0..28e3f4904a9 100644
--- a/doc/user/profile/active_sessions.md
+++ b/doc/user/profile/active_sessions.md
@@ -4,7 +4,7 @@
 >   in GitLab 10.8.
 
 GitLab lists all devices that have logged into your account. This allows you to
-review the sessions and revoke any of it that you don't recognize.
+review the sessions.
 
 ## Listing all active sessions
 
@@ -12,9 +12,3 @@ review the sessions and revoke any of it that you don't recognize.
 1. Navigate to the **Active Sessions** tab.
 
 ![Active sessions list](img/active_sessions_list.png)
-
-## Revoking a session
-
-1. Navigate to your [profile's](#profile-settings) **Settings > Active Sessions**.
-1. Click on **Revoke** besides a session. The current session cannot be
-   revoked, as this would sign you out of GitLab.
diff --git a/doc/user/profile/img/active_sessions_list.png b/doc/user/profile/img/active_sessions_list.png
index 5d94dca69cc..1e242ac4710 100644
--- a/doc/user/profile/img/active_sessions_list.png
+++ b/doc/user/profile/img/active_sessions_list.png
diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md
index a2b15d058d7..b216b9f255c 100644
--- a/doc/user/profile/index.md
+++ b/doc/user/profile/index.md
@@ -39,7 +39,7 @@ From there, you can:
 - Manage [personal access tokens](personal_access_tokens.md) to access your account via API and authorized applications
 - Add and delete emails linked to your account
 - Choose which email to use for notifications, web-based commits, and display on your public profile
-- Manage [SSH keys](../../ssh/README.md#ssh) to access your account via SSH
+- Manage [SSH keys](../../ssh/README.md) to access your account via SSH
 - Manage your [preferences](preferences.md#syntax-highlighting-theme)
   to customize your own GitLab experience
 - [View your active sessions](active_sessions.md) and revoke any of them if necessary
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index 0c514e005b2..6e64053a6ca 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -88,7 +88,7 @@ To add an existing Kubernetes cluster to your project:
 1. Click **Add an existing Kubernetes cluster** and fill in the details:
     - **Kubernetes cluster name** (required) - The name you wish to give the cluster.
     - **Environment scope** (required) - The
-      [associated environment](#setting-the-environment-scope) to this cluster.
+      [associated environment](#setting-the-environment-scope-premium) to this cluster.
     - **API URL** (required) -
       It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
       exposes several APIs, we want the "base" URL that is common to all of them,
@@ -473,7 +473,7 @@ project. That way you can have different clusters for different environments,
 like dev, staging, production, etc.
 
 Simply add another cluster, like you did the first time, and make sure to
-[set an environment scope](#setting-the-environment-scope) that will
+[set an environment scope](#setting-the-environment-scope-premium) that will
 differentiate the new cluster with the rest.
 
 ## Setting the environment scope **[PREMIUM]**
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index 2871510d5ed..856ae03f4bc 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -114,28 +114,35 @@ Follow these steps to deploy a function using the Node.js runtime to your Knativ
     - Public, continue to the next step.
     - Private, you will need to [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope.
 
-1. `.gitlab-ci.yml`: This template allows to define the stage, environment, and
-   image to be used for your functions. It must be included at the root of your repository:
+1. `.gitlab-ci.yml`: this defines a pipeline used to deploy your functions.
+   It must be included at the root of your repository:
 
    ```yaml
-   stages:
-     - deploy
+   include:
+     template: Serverless.gitlab-ci.yml
 
    functions:
-     stage: deploy
-     environment: test
-     image: gcr.io/triggermesh/tm:v0.0.9
-     script:
-      - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password "$CI_JOB_TOKEN" --push
-      - tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_DEPLOY_USER" --password "$CI_DEPLOY_PASSWORD" --pull
-      - tm -n "$KUBE_NAMESPACE" deploy --wait
-
+     extends: .serverless:deploy:functions
+     environment: production
    ```
 
-    The `gitlab-ci.yml` template creates a `Deploy` stage with a `functions` job that invokes the `tm` CLI with the required parameters.
+    This `.gitlab-ci.yml` creates a `functions` job that invokes some
+    predefined commands to deploy your functions to your cluster.
+
+    `Serverless.gitlab-ci.yml` is a template that allows customization.
+    You can either import it with `include` parameter and use `extends` to
+    customize your jobs, or you can inline the entire template by choosing it
+    from **Apply a template** dropdown when editing the `.gitlab-ci.yml` file through
+    the user interface.
+
+2. `serverless.yml`: this file contains the metadata for your functions,
+   such as name, runtime, and environment.
 
-2. `serverless.yml`: This file contains the metadata for your functions,
-   such as name, runtime, and environment. It must be included at the root of your repository. The following is a sample `echo` function which shows the required structure for the file. You can find the relevant files for this project in the [functions example project](https://gitlab.com/knative-examples/functions).
+   It must be included at the root of your repository.
+   The following is a sample `echo` function which shows the required structure
+   for the file.
+
+   You can find the relevant files for this project in the [functions example project](https://gitlab.com/knative-examples/functions).
 
    ```yaml
    service: my-functions
@@ -234,32 +241,22 @@ Add the following `.gitlab-ci.yml` to the root of your repository
 (you may skip this step if you've previously cloned the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned above):
 
 ```yaml
-stages:
-  - build
-  - deploy
+include:
+  template: Serverless.gitlab-ci.yml
 
 build:
-  stage: build
-  image:
-    name: gcr.io/kaniko-project/executor:debug
-    entrypoint: [""]
-  only:
-    - master
-  script:
-    - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
-    - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE
+  extends: .serverless:build:image
 
 deploy:
-  stage: deploy
-  image: gcr.io/triggermesh/tm@sha256:e3ee74db94d215bd297738d93577481f3e4db38013326c90d57f873df7ab41d5
-  only:
-    - master
-  environment: production
-  script:
-    - echo "$CI_REGISTRY_IMAGE"
-    - tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait
+  extends: .serverless:deploy:image
 ```
 
+`Serverless.gitlab-ci.yml` is a template that allows customization.
+You can either import it with `include` parameter and use `extends` to
+customize your jobs, or you can inline the entire template by choosing it
+from **Apply a template** dropdown when editing the `.gitlab-ci.yml` file through
+the user interface.
+
 ### Deploy the application with Knative
 
 With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to
diff --git a/doc/user/project/import/svn.md b/doc/user/project/import/svn.md
index a5923986292..4825b005a85 100644
--- a/doc/user/project/import/svn.md
+++ b/doc/user/project/import/svn.md
@@ -8,7 +8,7 @@ between the two, for more information consult your favorite search engine.
 
 There are two approaches to SVN to Git migration:
 
-1. [Git/SVN Mirror](#smooth-migration-with-a-git-svn-mirror-using-subgit) which:
+1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which:
     - Makes the GitLab repository to mirror the SVN project.
     - Git and SVN repositories are kept in sync; you can use either one.
     - Smoothens the migration process and allows to manage migration risks.
diff --git a/doc/user/project/index.md b/doc/user/project/index.md
index 0dc50d28cb0..4148310dc98 100644
--- a/doc/user/project/index.md
+++ b/doc/user/project/index.md
@@ -137,7 +137,7 @@ and Git push/pull redirects.
 Depending on the situation, different things apply.
 
 When [renaming a user](../profile/index.md#changing-your-username),
-[changing a group path](../group/index.md#changing-a-group-s-path) or [renaming a repository](settings/index.md#renaming-a-repository):
+[changing a group path](../group/index.md#changing-a-groups-path) or [renaming a repository](settings/index.md#renaming-a-repository):
 
 - Existing web URLs for the namespace and anything under it (e.g., projects) will
   redirect to the new URLs.
diff --git a/doc/user/project/integrations/mattermost_slash_commands.md b/doc/user/project/integrations/mattermost_slash_commands.md
index e031dcad2c3..9c69437537a 100644
--- a/doc/user/project/integrations/mattermost_slash_commands.md
+++ b/doc/user/project/integrations/mattermost_slash_commands.md
@@ -152,7 +152,7 @@ trigger word followed by <kbd>help</kbd>. Example: <samp>/gitlab help</samp>
 ## Permissions
 
 The permissions to run the [available commands](#available-slash-commands) derive from
-the [permissions you have on the project](../../permissions.md#project).
+the [permissions you have on the project](../../permissions.md#project-members-permissions).
 
 ## Further reading
 
diff --git a/doc/user/project/integrations/prometheus.md b/doc/user/project/integrations/prometheus.md
index ed289b0c4eb..26989e2a8a4 100644
--- a/doc/user/project/integrations/prometheus.md
+++ b/doc/user/project/integrations/prometheus.md
@@ -120,7 +120,7 @@ If the "No data found" screen continues to appear, it could be due to:
 - No successful deployments have occurred to this environment.
 - Prometheus does not have performance data for this environment, or the metrics
   are not labeled correctly. To test this, connect to the Prometheus server and
-  [run a query](#gitlab-prometheus-queries), replacing `$CI_ENVIRONMENT_SLUG`
+  [run a query](prometheus_library/kubernetes.html#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG`
   with the name of your environment.
 
 [autodeploy]: ../../../ci/autodeploy/index.md
diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md
index 9a95fb70964..f1e2771dcb9 100644
--- a/doc/user/project/pages/getting_started_part_one.md
+++ b/doc/user/project/pages/getting_started_part_one.md
@@ -59,7 +59,7 @@ which is highly recommendable and much faster than hardcoding.
 
 If you set up a GitLab Pages project on GitLab.com,
 it will automatically be accessible under a
-[subdomain of `namespace.gitlab.io`](introduction.md#gitlab-pages-on-gitlab-com).
+[subdomain of `namespace.gitlab.io`](introduction.md#gitlab-pages-on-gitlabcom).
 The `namespace` is defined by your username on GitLab.com,
 or the group name you created this project under.
 
diff --git a/doc/user/project/pages/getting_started_part_three.md b/doc/user/project/pages/getting_started_part_three.md
index daae2f4b5a3..756b8b698c7 100644
--- a/doc/user/project/pages/getting_started_part_three.md
+++ b/doc/user/project/pages/getting_started_part_three.md
@@ -20,13 +20,13 @@ you should consider first, which we'll cover in this guide:
 
 1. Either if you're adding a **root domain** or a **subdomain**, for which
    you'll need to set up [DNS records](#dns-records)
-1. Whether you want to add an [SSL/TLS certificate](#ssl-tls-certificates) or not
+1. Whether you want to add an [SSL/TLS certificate](#ssltls-certificates) or not
 
 To finish the association, you need to [add your domain to your project's Pages settings](#add-your-custom-domain-to-gitlab-pages-settings).
 
 Let's start from the beginning with [DNS records](#dns-records).
 If you already know how they work and want to skip the introduction to DNS,
-you may be interested in skipping it until the [TL;DR](#tl-dr) section below.
+you may be interested in skipping it until the [TL;DR](#tldr) section below.
 
 ### DNS Records
 
@@ -148,7 +148,7 @@ verify your domain's ownership with a TXT record:
 
 Once you've set the DNS record, you'll need navigate to your project's
 **Setting > Pages** and click **+ New domain** to add your custom domain to
-GitLab Pages. You can choose whether to add an [SSL/TLS certificate](#ssl-tls-certificates)
+GitLab Pages. You can choose whether to add an [SSL/TLS certificate](#ssltls-certificates)
 to make your website accessible under HTTPS or leave it blank. If don't add a certificate,
 your site will be accessible only via HTTP:
 
diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md
index e0b78753e21..ee471fa6534 100644
--- a/doc/user/project/pages/index.md
+++ b/doc/user/project/pages/index.md
@@ -141,7 +141,7 @@ You can also take some optional further steps:
 _Advanced options:_
 
 - [Use a custom domain](getting_started_part_three.md#adding-your-custom-domain-to-gitlab-pages)
-- Apply [SSL/TLS certification](getting_started_part_three.md#ssl-tls-certificates) to your custom domain
+- Apply [SSL/TLS certification](getting_started_part_three.md#ssltls-certificates) to your custom domain
 
 ## Explore GitLab Pages
 
diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md
index 23eb88fd305..6bb58689f38 100644
--- a/doc/user/project/pages/introduction.md
+++ b/doc/user/project/pages/introduction.md
@@ -11,7 +11,7 @@ With GitLab Pages you can host for free your static websites on GitLab.
 Combined with the power of [GitLab CI] and the help of [GitLab Runner] you can
 deploy static pages for your individual projects, your user or your group.
 
-Read [GitLab Pages on GitLab.com](#gitlab-pages-on-gitlab-com) for specific
+Read [GitLab Pages on GitLab.com](#gitlab-pages-on-gitlabcom) for specific
 information, if you are using GitLab.com to host your website.
 
 ## Getting started with GitLab Pages domains
@@ -410,7 +410,7 @@ file for both the `/data` and `/data/` URL paths.
 ### Add a custom domain to your Pages website
 
 For a complete guide on Pages domains, read through the article
-[GitLab Pages from A to Z: Part 3 - Setting Up Custom Domains - DNS Records and SSL/TLS Certificates](getting_started_part_three.md#setting-up-custom-domains-dns-records-and-ssl-tls-certificates)
+[GitLab Pages from A to Z: Part 3 - GitLab Pages custom domains and SSL/TLS Certificates](getting_started_part_three.md)
 
 If this setting is enabled by your GitLab administrator, you should be able to
 see the **New Domain** button when visiting your project's settings through the
@@ -451,7 +451,7 @@ private key when adding a new domain.
 ![Pages upload cert](img/pages_upload_cert.png)
 
 For a complete guide on Pages domains, read through the article
-[GitLab Pages from A to Z: Part 3 - Setting Up Custom Domains - DNS Records and SSL/TLS Certificates](getting_started_part_three.md#setting-up-custom-domains-dns-records-and-ssl-tls-certificates)
+[GitLab Pages from A to Z: Part 3 - GitLab Pages custom domains and SSL/TLS Certificates](getting_started_part_three.md)
 
 ### Custom error codes pages
 
diff --git a/doc/user/project/pipelines/job_artifacts.md b/doc/user/project/pipelines/job_artifacts.md
index bf939dbdaa3..8b57129c9e1 100644
--- a/doc/user/project/pipelines/job_artifacts.md
+++ b/doc/user/project/pipelines/job_artifacts.md
@@ -38,7 +38,7 @@ turn are defined with the `paths` keyword. All paths to files and directories
 are relative to the repository that was cloned during the build. These uploaded
 artifacts will be kept in GitLab for 1 week as defined by the `expire_in`
 definition. You have the option to keep the artifacts from expiring via the
-[web interface](#browsing-job-artifacts). If the expiry time is not defined,
+[web interface](#browsing-artifacts). If the expiry time is not defined,
 it defaults to the [instance wide
 setting](../../admin_area/settings/continuous_integration.md#default-artifacts-expiration-core-only).
 
diff --git a/doc/user/project/repository/branches/index.md b/doc/user/project/repository/branches/index.md
index f05554ffc5b..13e4f2ce163 100644
--- a/doc/user/project/repository/branches/index.md
+++ b/doc/user/project/repository/branches/index.md
@@ -11,7 +11,7 @@ Read through GiLab's branching documentation:
 See also:
 
 - [Branches API](../../../../api/branches.md), for information on operating on repository branches using the GitLab API.
-- [GitLab Flow](../../../../university/training/gitlab_flow.md#gitlab-flow). Use the best of GitLab for your branching strategies.
+- [GitLab Flow](../../../../university/training/gitlab_flow.md). Use the best of GitLab for your branching strategies.
 - [Getting started with Git](../../../../topics/git/index.md) and GitLab.
 
 ## Default branch
diff --git a/doc/user/search/index.md b/doc/user/search/index.md
index 770cef42995..705983cce2a 100644
--- a/doc/user/search/index.md
+++ b/doc/user/search/index.md
@@ -96,7 +96,7 @@ quickly access issues and merge requests created or assigned to you within that
 Your [todos](../../workflow/todos.md#gitlab-todos) can be searched by "to do" and "done".
 You can [filter](../../workflow/todos.md#filtering-your-todos) them per project,
 author, type, and action. Also, you can sort them by
-[**Label priority**](../../user/project/labels.md#prioritize-labels),
+[**Label priority**](../../user/project/labels.md#label-priority),
 **Last created** and **Oldest created**.
 
 ## Projects