Add latest changes from gitlab-org/gitlab@master

3 files changed, 13 insertions, 10 deletions

diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 58e802a9d27..78fbd421b4d 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -38,13 +38,13 @@ To run rspec tests:
 
 ```shell
 # run all tests
-bundle exec rspec
+bin/rspec
 
 # run test for path
-bundle exec rspec spec/[path]/[to]/[spec].rb
+bin/rspec spec/[path]/[to]/[spec].rb
 ```
 
-Use [guard](https://github.com/guard/guard) to continuously monitor for changes and only run matching tests:
+Use [Guard](https://github.com/guard/guard) to continuously monitor for changes and only run matching tests:
 
 ```shell
 bundle exec guard
@@ -130,7 +130,7 @@ Note: `live_debug` only works on JavaScript enabled specs.
 Run the spec with `CHROME_HEADLESS=0`, e.g.:
 
 ```
-CHROME_HEADLESS=0 bundle exec rspec some_spec.rb
+CHROME_HEADLESS=0 bin/rspec some_spec.rb
 ```
 
 The test will go by quickly, but this will give you an idea of what's happening.
@@ -382,8 +382,8 @@ this trait should be either fixed to not rely on Sidekiq processing jobs, or the
 the processing of background jobs is needed/expected.
 
 NOTE: **Note:**
-The usage of `perform_enqueued_jobs` is currently useless since our
-workers aren't inheriting from `ApplicationJob` / `ActiveJob::Base`.
+The usage of `perform_enqueued_jobs` is only useful for testing delayed mail
+deliveries since our Sidekiq workers aren't inheriting from `ApplicationJob` / `ActiveJob::Base`.
 
 #### DNS
 
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index 94c45f5d2f7..5015c613557 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -50,6 +50,9 @@ is detected in any other branch (`flaky-examples-check` job). In the future, the
 
 This was originally implemented in: <https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/13021>.
 
+If you want to enable retries locally, you can use the `RETRIES` env variable.
+For instance `RETRIES=1 bin/rspec ...` would retry the failing examples once.
+
 [rspec-retry]: https://github.com/NoRedInk/rspec-retry
 [`spec/spec_helper.rb`]: https://gitlab.com/gitlab-org/gitlab/blob/master/spec/spec_helper.rb
 
diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md
index ef491a1971d..b52bff31794 100644
--- a/doc/user/project/clusters/add_remove_clusters.md
+++ b/doc/user/project/clusters/add_remove_clusters.md
@@ -232,8 +232,8 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
    - **Number of nodes** - Enter the number of nodes you wish the cluster to have.
    - **Machine type** - The [machine type](https://cloud.google.com/compute/docs/machine-types)
      of the Virtual Machine instance that the cluster will be based on.
-   - **Enable Cloud Run on GKE (beta)** - Check this if you want to use Cloud Run on GKE for this cluster.
-     See the [Cloud Run on GKE section](#cloud-run-on-gke) for more information.
+   - **Enable Cloud Run for Anthos** - Check this if you want to use Cloud Run for Anthos for this cluster.
+     See the [Cloud Run for Anthos section](#cloud-run-for-anthos) for more information.
    - **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster.
      See the [Managed clusters section](index.md#gitlab-managed-clusters) for more information.
 1. Finally, click the **Create Kubernetes cluster** button.
@@ -241,11 +241,11 @@ To create and add a new Kubernetes cluster to your project, group, or instance:
 After a couple of minutes, your cluster will be ready to go. You can now proceed
 to install some [pre-defined applications](index.md#installing-applications).
 
-#### Cloud Run on GKE
+#### Cloud Run for Anthos
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/16566) in GitLab 12.4.
 
-You can choose to use Cloud Run on GKE in place of installing Knative and Istio
+You can choose to use Cloud Run for Anthos in place of installing Knative and Istio
 separately after the cluster has been created. This means that Cloud Run
 (Knative), Istio, and HTTP Load Balancing will be enabled on the cluster at
 create time and cannot be [installed or uninstalled](../../clusters/applications.md) separately.