Add latest changes from gitlab-org/gitlab@13-6-stable-eev13.6.0-rc42

7 files changed, 24 insertions, 22 deletions

diff --git a/doc/ci/examples/README.md b/doc/ci/examples/README.md
index 34e3b276d3e..1abb33005ca 100644
--- a/doc/ci/examples/README.md
+++ b/doc/ci/examples/README.md
@@ -15,7 +15,7 @@ Examples are available in several forms. As a collection of:
 
 - `.gitlab-ci.yml` [template files](#cicd-templates) maintained in GitLab, for many
   common frameworks and programming languages.
-- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include demonstrations of [multi-project pipelines](https://gitlab.com/gitlab-examples/multi-project-pipelines) and using [Review Apps with a static site served by NGINX](https://gitlab.com/gitlab-examples/review-apps-nginx/).
+- Repositories with [example projects](https://gitlab.com/gitlab-examples) for various languages. You can fork and adjust them to your own needs. Projects include an example of using [Review Apps with a static site served by NGINX](https://gitlab.com/gitlab-examples/review-apps-nginx/).
 - Examples and [other resources](#other-resources) listed below.
 
 ## CI/CD examples
@@ -42,6 +42,7 @@ The following table lists examples with step-by-step tutorials that are containe
 | Scala on Heroku               | [Test and deploy a Scala application to Heroku](test-scala-application.md).                                                |
 | Parallel testing Ruby & JS    | [GitLab CI/CD parallel jobs testing for Ruby & JavaScript projects](https://docs.knapsackpro.com/2019/how-to-run-parallel-jobs-for-rspec-tests-on-gitlab-ci-pipeline-and-speed-up-ruby-javascript-testing). |
 | Secrets management with Vault | [Authenticating and Reading Secrets With Hashicorp Vault](authenticating-with-hashicorp-vault/index.md).                    |
+| Multi project pipeline | [Build, test deploy using multi project pipeline](https://gitlab.com/gitlab-examples/upstream-project).                    |
 
 ### Contributing examples
 
diff --git a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
index 4a0ff2fa6ac..c0fb94acdf2 100644
--- a/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
+++ b/doc/ci/examples/authenticating-with-hashicorp-vault/index.md
@@ -22,7 +22,8 @@ This tutorial assumes you are familiar with GitLab CI/CD and Vault.
 To follow along, you will need:
 
 - An account on GitLab.
-- A running Vault server and the access required to configure authentication and create roles and policies.
+- A running Vault server and access to it is required to configure authentication and create roles
+  and policies. For HashiCorp Vaults, this can be the Open Source or Enterprise version.
 
 NOTE: **Note:**
 You will need to replace the `vault.example.com` URL below with the URL of your Vault server and `gitlab.example.com` with the URL of your GitLab instance.
@@ -55,7 +56,7 @@ The JWT's payload looks like this:
 }
 ```
 
-The JWT is encoded by using RS256 and signed with your GitLab instance's OpenID Connect private key. The expire time for the token will be set to job's timeout, if specified, or 5 minutes if it is not. The key used to sign this token may change without any notice. In such case retrying the job will generate new JWT using the current signing key.
+The JWT is encoded by using RS256 and signed with a dedicated private key. The expire time for the token will be set to job's timeout, if specified, or 5 minutes if it is not. The key used to sign this token may change without any notice. In such case retrying the job will generate new JWT using the current signing key.
 
 You can use this JWT and your instance's JWKS endpoint (`https://gitlab.example.com/-/jwks`) to authenticate with a Vault server that is configured to allow the JWT Authentication method for authentication.
 
diff --git a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
index b113b10f2e3..25b866a08ed 100644
--- a/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
+++ b/doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
@@ -103,27 +103,27 @@ Hub](https://hub.docker.com/). We've also added the [`only`
 clause](../../yaml/README.md#onlyexcept-basic)
 to ensure our deployments only happen when we push to the master branch.
 
-Now, since the steps defined in `.gitlab-ci.yml` require credentials to login
-to CF, you'll need to add your CF credentials as [environment
-variables](../../variables/README.md#predefined-environment-variables)
-on GitLab CI/CD. To set the environment variables, navigate to your project's
-**Settings > CI/CD** and expand **Variables**. Name the variables
+Because the steps defined in `.gitlab-ci.yml` require credentials to sign in to
+CF, you'll need to add your CF credentials as
+[environment variables](../../variables/README.md#predefined-environment-variables)
+in GitLab CI/CD. To set the environment variables, navigate to your project's
+**Settings > CI/CD**, and then expand **Variables**. Name the variables
 `CF_USERNAME` and `CF_PASSWORD` and set them to the correct values.
 
 ![Variable Settings in GitLab](img/cloud_foundry_variables.png)
 
-Once set up, GitLab CI/CD will deploy your app to CF at every push to your
-repository's default branch. To see the build logs or watch your builds running
-live, navigate to **CI/CD > Pipelines**.
+After set up, GitLab CI/CD deploys your app to CF at every push to your
+repository's default branch. To review the build logs or watch your builds
+running live, navigate to **CI/CD > Pipelines**.
 
 CAUTION: **Caution:**
-It is considered best practice for security to create a separate deploy
-user for your application and add its credentials to GitLab instead of using
-a developer's credentials.
+It's considered best practice for security to create a separate deploy user for
+your application and add its credentials to GitLab instead of using a
+developer's credentials.
 
 To start a manual deployment in GitLab go to **CI/CD > Pipelines** then click
-on **Run Pipeline**. Once the app is finished deploying it will display the URL
-of your application in the logs for the `production` job like:
+on **Run Pipeline**. After the app is finished deploying, it will display the
+URL of your application in the logs for the `production` job like:
 
 ```shell
 requested state: started
diff --git a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
index 836141af91e..39cad3a0c93 100644
--- a/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
+++ b/doc/ci/examples/devops_and_game_dev_with_gitlab_ci_cd/index.md
@@ -249,7 +249,7 @@ pipeline to include running the tests along with the existing build job.
 
 ## Continuous Integration
 
-To ensure our changes don't break the build and all tests still pass, we utilize
+To ensure our changes don't break the build and all tests still pass, we use
 Continuous Integration (CI) to run these checks automatically for every push.
 Read through this article to understand [Continuous Integration, Continuous Delivery, and Continuous Deployment](https://about.gitlab.com/blog/2016/08/05/continuous-integration-delivery-and-deployment-with-gitlab/),
 and how these methods are leveraged by GitLab.
@@ -261,7 +261,7 @@ Please read through the [documentation on CI/CD configuration](../../../ci/yaml/
 ### Build your game with GitLab CI/CD
 
 We need to update our build job to ensure tests get run as well. Add `gulp build-test`
-to the end of the `script` array for the existing `build` job. Once these commands run,
+to the end of the `script` array for the existing `build` job. After these commands run,
 we know we will need to access everything in the `built` folder, given by GitLab CI/CD's `artifacts`.
 We'll also cache `node_modules` to avoid having to do a full re-pull of those dependencies:
 just pack them up in the cache. Here is the full `build` job:
diff --git a/doc/ci/examples/end_to_end_testing_webdriverio/index.md b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
index aa6e6f73a0d..42725e8aef9 100644
--- a/doc/ci/examples/end_to_end_testing_webdriverio/index.md
+++ b/doc/ci/examples/end_to_end_testing_webdriverio/index.md
@@ -14,7 +14,7 @@ environment, reducing the effort to assess the impact of changes. Thus, when we
 and it will immediately be clear that the application can still be properly built and deployed. After all, you can _see_ it
 running!
 
-<img src="img/deployed_dependency_update.png" alt="dependencies.io" class="image-noshadow">
+<img src="img/deployed_dependency_update.png" alt="dependencies.io">
 
 However, looking at the freshly deployed code to check whether it still looks and behaves as
 expected is repetitive manual work, which means it is a prime candidate for automation. This is
@@ -140,7 +140,7 @@ new browser window interacting with your app as you specified.
 Which brings us to the exciting part: how do we run this in GitLab CI/CD? There are two things we
 need to do for this:
 
-1. Set up [CI/CD jobs](../../yaml/README.md#introduction) that actually have a browser available.
+1. Set up [CI/CD jobs](../../yaml/README.md) that actually have a browser available.
 1. Update our WebdriverIO configuration to use those browsers to visit the review apps.
 
 For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages)
diff --git a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
index aaa34afeddf..f692a8042f5 100644
--- a/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
+++ b/doc/ci/examples/laravel_with_gitlab_and_envoy/index.md
@@ -632,7 +632,7 @@ After our code passed through the pipeline successfully, we can deploy to our pr
 
 ![pipelines page deploy button](img/pipelines_page_deploy_button.png)
 
-Once the deploy pipeline passed successfully, navigate to **Pipelines > Environments**.
+After the deploy pipeline passed successfully, navigate to **Pipelines > Environments**.
 
 ![environments page](img/environments_page.png)
 
diff --git a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
index c62f0dec598..9bc9ac5423e 100644
--- a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
+++ b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md
@@ -298,7 +298,7 @@ project.
     - mix ecto.migrate
    ```
 
-  This ensures that [rebar3](https://www.rebar3.org) and [hex](https://hex.pm) are both installed
+  This ensures that [rebar3](https://rebar3.org) and [hex](https://hex.pm) are both installed
   before attempting to fetch the dependencies that are required to run the tests. Next, the `postgres` db
   is created and migrated with `ecto`, to ensure it's up-to-date.