Add latest changes from gitlab-org/gitlab@14-7-stable-eev14.7.0-rc42

6 files changed, 70 insertions, 18 deletions

diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 0f768a51b66..fe0c4c13ba2 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -642,6 +642,11 @@ should either:
 It takes around one second to load tests that are using `fast_spec_helper`
 instead of 30+ seconds in case of a regular `spec_helper`.
 
+WARNING:
+To verify that code and its specs are well-isolated from Rails, run the spec
+individually via `bin/rspec`. Don't use `bin/spring rspec` as it loads
+`spec_helper` automatically.
+
 ### `subject` and `let` variables
 
 The GitLab RSpec suite has made extensive use of `let`(along with its strict, non-lazy
diff --git a/doc/development/testing_guide/ci.md b/doc/development/testing_guide/ci.md
deleted file mode 100644
index de024084c9c..00000000000
--- a/doc/development/testing_guide/ci.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-redirect_to: '../pipelines.md'
-remove_date: '2022-01-12'
----
-
-This file was moved to [another location](../pipelines.md).
-
-<!-- This redirect file can be deleted after <2022-01-12>. -->
-<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
diff --git a/doc/development/testing_guide/end_to_end/feature_flags.md b/doc/development/testing_guide/end_to_end/feature_flags.md
index de34e6a1872..48157a961e1 100644
--- a/doc/development/testing_guide/end_to_end/feature_flags.md
+++ b/doc/development/testing_guide/end_to_end/feature_flags.md
@@ -118,6 +118,32 @@ view 'app/views/devise/passwords/new_edit_behind_ff.html.haml' do
 end
 ```
 
+## Working with resource classes
+
+If a resource class must behave differently when a feature flag is active, toggle a
+variable with the name of the feature flag inside the class. This variable and condition
+ensure all actions are handled appropriately.
+
+You can set this variable inside the `fabricate_via_api` call. For a consistent approach:
+
+- Use an `activated` check, not a deactivated one.
+- Add the word `activated` to the end of a variable's name.
+- Inside the `initialize` method, set the variable's default value.
+
+For example: 
+
+```ruby
+def initialize
+  name_of_the_future_flag_activated = false
+  ...
+end
+```
+
+### Cleanup
+
+After the feature flag is removed, clean up the resource class and delete the variable.
+All methods should use the condition procedures of the now-default state.
+
 ## Running a scenario with a feature flag enabled
 
 It's also possible to run an entire scenario with a feature flag enabled, without having to edit
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 57c8c3bf59c..1fc9bc8258a 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -170,6 +170,35 @@ Helm chart](https://gitlab.com/gitlab-org/charts/gitlab/), itself deployed with
 
 See [Review Apps](../review_apps.md) for more details about Review Apps.
 
+### Run tests in parallel
+
+To run tests in parallel on CI, the [Knapsack](https://github.com/KnapsackPro/knapsack)
+gem is used. Knapsack reports are generated automatically and stored in the `GCS` bucket
+`knapsack-reports` in the `gitlab-qa-resources` project. The [`KnapsackReport`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/qa/qa/tools/knapsack_report.rb)
+helper handles automated report generation and upload.
+
+## Test metrics
+
+For additional test health visibility, use a custom setup to export test execution
+results to your [InfluxDb](https://influxdb.quality.gitlab.net/) instance, and visualize
+results as [Grafana](https://dashboards.quality.gitlab.net/) dashboards.
+
+### Provisioning
+
+Provisioning of all components is performed by the
+[`engineering-productivity-infrastructure`](https://gitlab.com/gitlab-org/quality/engineering-productivity-infrastructure) project.
+
+### Exporting metrics in CI
+
+Use these environment variables to configure metrics export:
+
+| Variable | Required | Information |
+| -------- | -------- | ----------- |
+| `QA_INFLUXDB_URL` | `true` | Should be set to `https://influxdb.quality.gitlab.net`. No default value. |
+| `QA_INFLUXDB_TOKEN` | `true` | InfluxDB write token that can be found under `Influxdb auth tokens` document in `Gitlab-QA` `1Password` vault. No default value. |
+| `QA_RUN_TYPE` | `false` | Arbitrary name for test execution, like `package-and-qa`. Automatically inferred from the project name for live environment test executions. No default value. |
+| `QA_EXPORT_TEST_METRICS` | `false` | Flag to enable or disable metrics export. Defaults to `true`. |
+
 ## Test reports
 
 ### Allure report
diff --git a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
index cb15dbe023f..bb214976926 100644
--- a/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
+++ b/doc/development/testing_guide/end_to_end/rspec_metadata_tests.md
@@ -34,7 +34,7 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
 | `:packages`       | The test requires a GitLab instance that has the [Package Registry](../../../administration/packages/#gitlab-package-registry-administration) enabled. |
 | `:quarantine`     | The test has been [quarantined](https://about.gitlab.com/handbook/engineering/quality/guidelines/debugging-qa-test-failures/#quarantining-tests), runs in a separate job that only includes quarantined tests, and is allowed to fail. The test is skipped in its regular job so that if it fails it doesn't hold up the pipeline. Note that you can also [quarantine a test only when it runs in a specific context](execution_context_selection.md#quarantine-a-test-for-a-specific-environment). |
 | `:relative_url`   | The test requires a GitLab instance to be installed under a [relative URL](../../../install/relative_url.md). |
-| `: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. |
+| `:reliable`       | The test has been [promoted to a reliable test](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/reliable-tests/#promoting-an-existing-test-to-reliable) meaning it passes consistently in all pipelines, including merge requests. |
 | `:repository_storage` |  The test requires a GitLab instance to be configured to use multiple [repository storage paths](../../../administration/repository_storage_paths.md). Paired with the `:orchestrated` tag. |
 | `:requires_admin` | The test requires an administrator account. Tests with the tag are excluded when run against Canary and Production environments. |
 | `:requires_git_protocol_v2`   | The test requires that Git protocol version 2 is enabled on the server. It's assumed to be enabled by default but if not the test can be skipped by setting `QA_CAN_TEST_GIT_PROTOCOL_V2` to `false`. |
@@ -46,4 +46,4 @@ This is a partial list of the [RSpec metadata](https://relishapp.com/rspec/rspec
 | `:smtp`           | The test requires a GitLab instance to be configured to use an SMTP server. Tests SMTP notification email delivery from GitLab by using MailHog. |
 | `:testcase`       | The link to the test case issue in the [GitLab Project Test Cases](https://gitlab.com/gitlab-org/gitlab/-/quality/test_cases). |
 | `:transient`      | The test tests transient bugs. It is excluded by default. |
-| `:issue`, `:issue_${num}` | Optional links to issues which might be related to the spec. Helps keeping track of related issues and can also be used by tools that create test reports. Currently added automatically to `Allure` test report. Multiple tags can be used by adding optional number postfix like `issue_1`, `issue_2` etc. |
+| `:issue`, `:issue_${num}` | Optional links to issues which might be related to the spec. Helps keep track of related issues and can also be used by tools that create test reports. Currently added automatically to `Allure` test report. Multiple tags can be used by adding an optional numeric suffix like `issue_1`, `issue_2` etc. |
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 31a807697c5..aef83109b9b 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -14,6 +14,7 @@ For any of the following scenarios, the `start-review-app-pipeline` job would be
 
 - for merge requests with CI config changes
 - for merge requests with frontend changes
+- for merge requests with changes to `{,ee/,jh/}{app/controllers}/**/*`
 - for merge requests with QA changes
 - for scheduled pipelines
 - the MR has the `pipeline:run-review-app` label set
@@ -21,13 +22,13 @@ For any of the following scenarios, the `start-review-app-pipeline` job would be
 ## QA runs on Review Apps
 
 On every [pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/125315730) in the `qa` stage (which comes after the
-`review` stage), the `review-qa-smoke` job is automatically started and it runs
-the QA smoke suite.
+`review` stage), the `review-qa-smoke` and `review-qa-reliable` jobs are automatically started. The `review-qa-smoke` runs
+the QA smoke suite and the `review-qa-reliable` executes E2E tests identified as [reliable](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/reliable-tests).
 
 You can also manually start the `review-qa-all`: it runs the full QA suite.
 
 After the end-to-end test runs have finished, [Allure reports](https://github.com/allure-framework/allure2) are generated and published by
-the `allure-report-qa-smoke` and `allure-report-qa-all` jobs. A comment with links to the reports are added to the merge request.
+the `allure-report-qa-smoke`, `allure-report-qa-reliable`, and `allure-report-qa-all` jobs. A comment with links to the reports are added to the merge request.
 
 ## Performance Metrics
 
@@ -121,7 +122,7 @@ graph TD
   B[review-build-cng];
   C[review-deploy];
   D[CNG-mirror];
-  E[review-qa-smoke];
+  E[review-qa-smoke, review-qa-reliable];
 
   A -->|once the `prepare` stage is done| B
   B -.->|triggers a CNG-mirror pipeline and wait for it to be done| D
@@ -142,7 +143,7 @@ subgraph "3. gitlab `review` stage"
   end
 
 subgraph "4. gitlab `qa` stage"
-  E[review-qa-smoke<br><br>gitlab-qa runs the smoke suite against the Review App.]
+  E[review-qa-smoke, review-qa-reliable<br><br>gitlab-qa runs the smoke and reliable suites against the Review App.]
   end
 
 subgraph "CNG-mirror pipeline"
@@ -196,7 +197,7 @@ subgraph "CNG-mirror pipeline"
   issue with a link to your merge request. Note that the deployment failure can
   reveal an actual problem introduced in your merge request (that is, this isn't
   necessarily a transient failure)!
-- If the `review-qa-smoke` job keeps failing (note that we already retry it twice),
+- If the `review-qa-smoke` or `review-qa-reliable` job keeps failing (note that we already retry them once),
   please check the job's logs: you could discover an actual problem introduced in
   your merge request. You can also download the artifacts to see screenshots of
   the page at the time the failures occurred. If you don't find the cause of the
@@ -250,7 +251,7 @@ Leading indicators may be health check failures leading to restarts or majority
 The [Review Apps Overview dashboard](https://console.cloud.google.com/monitoring/classic/dashboards/6798952013815386466?project=gitlab-review-apps&timeDomain=1d)
 aids in identifying load spikes on the cluster, and if nodes are problematic or the entire cluster is trending towards unhealthy.
 
-### Database related errors in `review-deploy` or `review-qa-smoke`
+### Database related errors in `review-deploy`, `review-qa-smoke`, or `review-qa-reliable`
 
 Occasionally the state of a Review App's database could diverge from the database schema. This could be caused by
 changes to migration files or schema, such as a migration being renamed or deleted. This typically manifests in migration errors such as: