Add latest changes from gitlab-org/gitlab@master

doc/development/event_tracking/frontend.md

@@ -149,12 +149,12 @@ import { mockTracking, triggerEvent } from 'spec/helpers/tracking_helper';
 describe('my component', () => {
   let trackingSpy;
-  
+
   beforeEach(() => {
     const vm = mountComponent(MyComponent);
     trackingSpy = mockTracking('_category_', vm.$el, spyOn);
   });
-  
+
   it('tracks an event when toggled', () => {
     triggerEvent('a.toggle');

doc/development/import_export.md

@@ -195,17 +195,17 @@ module Gitlab
 The [current version history](../user/project/settings/import_export.md) also displays the equivalent GitLab version
 and it is useful for knowing which versions won't be compatible between them.
-| Exporting GitLab version   | Importing GitLab version   |  
-| -------------------------- | -------------------------- |  
-| 11.7 to current            | 11.7 to current            |  
-| 11.1 to 11.6               | 11.1 to 11.6               |  
-| 10.8 to 11.0               | 10.8 to 11.0               |  
-| 10.4 to 10.7               | 10.4 to 10.7               |  
-| ...                        | ...                        |  
-| 8.10.3 to 8.11             | 8.10.3 to 8.11             |  
-| 8.10.0 to 8.10.2           | 8.10.0 to 8.10.2           |  
-| 8.9.5 to 8.9.11            | 8.9.5 to 8.9.11            |  
-| 8.9.0 to 8.9.4             | 8.9.0 to 8.9.4             |  
+| Exporting GitLab version   | Importing GitLab version   |
+| -------------------------- | -------------------------- |
+| 11.7 to current            | 11.7 to current            |
+| 11.1 to 11.6               | 11.1 to 11.6               |
+| 10.8 to 11.0               | 10.8 to 11.0               |
+| 10.4 to 10.7               | 10.4 to 10.7               |
+| ...                        | ...                        |
+| 8.10.3 to 8.11             | 8.10.3 to 8.11             |
+| 8.10.0 to 8.10.2           | 8.10.0 to 8.10.2           |
+| 8.9.5 to 8.9.11            | 8.9.5 to 8.9.11            |
+| 8.9.0 to 8.9.4             | 8.9.0 to 8.9.4             |
 ### When to bump the version up

doc/development/integrations/secure.md

@@ -278,7 +278,7 @@ and where the `message` repeats the `location` field:
         It takes around 50k characters to block for 2 seconds making this a low severity issue."
 }
 ```
-  
+
 The `description` might explain how the vulnerability works or give context about the exploit.
 It should not repeat the other fields of the vulnerability object.
 In particular, the `description` should not repeat the `location` (what is affected)

doc/development/reference_processing.md

@@ -43,7 +43,7 @@ Subclasses of `AbstractReferenceFilter` generally do not override `#call`; inste
 a minimum implementation of `AbstractReferenceFilter` should define:
 - `.reference_type`: The type of domain object.
-  
+
   This is usually a keyword, and is used to set the `data-reference-type` attribute
   on the generated link, and is an important part of the interaction with the
   corresponding `ReferenceParser` (see below).

doc/development/testing_guide/end_to_end/rspec_metadata_tests.md

@@ -6,8 +6,10 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
 <!-- Please keep the tags in alphabetical order -->
 | Tag | Description |
-|-|-|
-| `:elasticsearch` | The test requires an Elasticsearch service. It is used by the [instance-level scenario](https://gitlab.com/gitlab-org/gitlab-qa#definitions) [`Test::Integration::Elasticsearch`](https://gitlab.com/gitlab-org/gitlab/-/blob/72b62b51bdf513e2936301cb6c7c91ec27c35b4d/qa/qa/ee/scenario/test/integration/elasticsearch.rb) to include only tests that require Elasticsearch. |
-| `:orchestrated` | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify GitLab's configuration (for example, Staging). |
-| `:quarantine` | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), will run in a separate job that only includes quarantined tests, and is allowed to fail. The test will be skipped in its regular job so that if it fails it will not hold up the pipeline. |
+|-----|-------------|
+| `:elasticsearch`  | The test requires an Elasticsearch service. It is used by the [instance-level scenario](https://gitlab.com/gitlab-org/gitlab-qa#definitions) [`Test::Integration::Elasticsearch`](https://gitlab.com/gitlab-org/gitlab/-/blob/72b62b51bdf513e2936301cb6c7c91ec27c35b4d/qa/qa/ee/scenario/test/integration/elasticsearch.rb) to include only tests that require Elasticsearch. |
+| `:kubernetes`     | The test includes a GitLab instance that is configured to be run behind an SSH tunnel, allowing a TLS-accessible GitLab. This test will also include provisioning of at least one Kubernetes cluster to test against. *This tag is often be paired with `:orchestrated`.* |
+| `:orchestrated`   | The GitLab instance under test may be [configured by `gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/-/blob/master/docs/what_tests_can_be_run.md#orchestrated-tests) to be different to the default GitLab configuration, or `gitlab-qa` may launch additional services in separate docker containers, or both. Tests tagged with `:orchestrated` are excluded when testing environments where we can't dynamically modify GitLab's configuration (for example, Staging). |
+| `:quarantine`     | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), will run in a separate job that only includes quarantined tests, and is allowed to fail. The test will be skipped in its regular job so that if it fails it will not hold up the pipeline. |
+| `:reliable`       | The test has been [promoted to a reliable test](https://about.gitlab.com/handbook/engineering/quality/guidelines/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |
 | `:requires_admin` | The test requires an admin account. Tests with the tag are excluded when run against Canary and Production environments. |

doc/install/aws/index.md

@@ -543,7 +543,7 @@ If everything looks good, you should be able to reach GitLab in your browser.
 ### Setting up Gitaly
-CAUTION: **Caution:** In this architecture, having a single Gitaly server creates a single point of failure. This limitation will be removed once [Gitaly HA](https://gitlab.com/groups/gitlab-org/-/epics/842) is released.  
+CAUTION: **Caution:** In this architecture, having a single Gitaly server creates a single point of failure. This limitation will be removed once [Gitaly HA](https://gitlab.com/groups/gitlab-org/-/epics/842) is released.
 Gitaly is a service that provides high-level RPC access to Git repositories.
 It should be enabled and configured on a separate EC2 instance in one of the

doc/integration/elasticsearch.md

@@ -54,7 +54,7 @@ The way you install the Go indexer depends on your version of GitLab:
 ### GitLab Omnibus
-Since GitLab 11.8 the Go indexer is included in GitLab Omnibus.  
+Since GitLab 11.8 the Go indexer is included in GitLab Omnibus.
 The former Ruby-based indexer was removed in [GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/issues/6481).
 ### From source