Add latest changes from gitlab-org/gitlab@13-9-stable-eev13.9.0-rc42

5 files changed, 24 insertions, 20 deletions

diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md
index 4dac076ffb7..eecc8ffd18f 100644
--- a/doc/ci/environments/deployment_safety.md
+++ b/doc/ci/environments/deployment_safety.md
@@ -110,7 +110,7 @@ for an explanation of these roles and the permissions of each.
 
 Production secrets are needed to deploy successfully. For example, when deploying to the cloud,
 cloud providers require these secrets to connect to their services. In the project settings, you can
-define and protect environment variables for these secrets. [Protected variables](../variables/README.md#protect-a-custom-variable)
+define and protect CI/CD variables for these secrets. [Protected variables](../variables/README.md#protect-a-custom-variable)
 are only passed to pipelines running on [protected branches](../../user/project/protected_branches.md)
 or [protected tags](../../user/project/protected_tags.md).
 The other pipelines don't get the protected variable. You can also
@@ -141,7 +141,7 @@ reference a file in another project with a completely different set of permissio
 In this scenario, the `gitlab-ci.yml` is publicly accessible, but can only be edited by users with
 appropriate permissions in the other project.
 
-For more information, see [Custom CI configuration path](../pipelines/settings.md#custom-ci-configuration-path).
+For more information, see [Custom CI/CD configuration path](../pipelines/settings.md#custom-cicd-configuration-path).
 
 ## Troubleshooting
 
diff --git a/doc/ci/environments/environments_dashboard.md b/doc/ci/environments/environments_dashboard.md
index 84f8b1b1dbf..ef222ba5779 100644
--- a/doc/ci/environments/environments_dashboard.md
+++ b/doc/ci/environments/environments_dashboard.md
@@ -36,7 +36,7 @@ environments are not displayed.
 
 To add a project to the dashboard:
 
-1. Click the **Add projects** button in the homescreen of the dashboard.
+1. Click the **Add projects** button in the home screen of the dashboard.
 1. Search and add one or more projects using the **Search your projects** field.
 1. Click the **Add projects** button.
 
@@ -53,4 +53,4 @@ You can add up to 150 projects for GitLab to display on this dashboard.
 
 GitLab.com users can add public projects to the Environments
 Dashboard for free. If your project is private, the group it belongs
-to must have a [GitLab Silver](https://about.gitlab.com/pricing/) plan.
+to must have a [GitLab Premium](https://about.gitlab.com/pricing/) plan.
diff --git a/doc/ci/environments/incremental_rollouts.md b/doc/ci/environments/incremental_rollouts.md
index 15eb4d2c526..39e3dd1ca75 100644
--- a/doc/ci/environments/incremental_rollouts.md
+++ b/doc/ci/environments/incremental_rollouts.md
@@ -117,6 +117,10 @@ available, [demonstrating configuration of timed rollouts](https://gitlab.com/gl
 
 ## Blue-Green Deployment
 
+NOTE:
+As of GitLab 13.7, teams can leverage an Ingress annotation and [set traffic weight](../../user/project/canary_deployments.md#how-to-change-the-traffic-weight-on-a-canary-ingress)
+as an alternative approach to the blue-green deployment strategy documented here.
+
 Also sometimes known as A/B deployment or red-black deployment, this technique is used to reduce
 downtime and risk during a deployment. When combined with incremental rollouts, you can
 minimize the impact of a deployment causing an issue.
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index 7bf30ef1b95..b49fcd72172 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -57,7 +57,7 @@ Configuring environments involves:
 The rest of this section illustrates how to configure environments and deployments using
 an example scenario. It assumes you have already:
 
-- Created a [project](../../gitlab-basics/create-project.md) in GitLab.
+- Created a [project](../../user/project/working_with_projects.md#create-a-project) in GitLab.
 - Set up [a runner](../runners/README.md).
 
 In the scenario:
@@ -135,12 +135,12 @@ In summary, with the above `.gitlab-ci.yml` we have achieved the following:
   job deploys our code to a staging server while the deployment
   is recorded in an environment named `staging`.
 
-#### Environment variables and runners
+#### CI/CD variables and runners
 
 Starting with GitLab 8.15, the environment name is exposed to the runner in
 two forms:
 
-- `$CI_ENVIRONMENT_NAME`. The name given in `.gitlab-ci.yml` (with any variables
+- `$CI_ENVIRONMENT_NAME`. The name given in `.gitlab-ci.yml` (with any CI/CD variables
   expanded).
 - `$CI_ENVIRONMENT_SLUG`. A "cleaned-up" version of the name, suitable for use in URLs,
   DNS, etc.
@@ -221,7 +221,7 @@ The assigned URL for the `review/your-branch-name` environment is [visible in th
 Note the following:
 
 - `stop_review` doesn't generate a dotenv report artifact, so it doesn't recognize the
-  `DYNAMIC_ENVIRONMENT_URL` variable. Therefore you shouldn't set `environment:url:` in the
+  `DYNAMIC_ENVIRONMENT_URL` environment variable. Therefore you shouldn't set `environment:url:` in the
   `stop_review` job.
 - If the environment URL isn't valid (for example, the URL is malformed), the system doesn't update
   the environment URL.
@@ -313,9 +313,9 @@ Dynamic environments are a fundamental part of [Review apps](../review_apps/inde
 The `name` and `url` keywords for dynamic environments can use most available CI/CD variables,
 including:
 
-- [Predefined environment variables](../variables/README.md#predefined-environment-variables)
-- [Project and group variables](../variables/README.md#gitlab-cicd-environment-variables)
-- [`.gitlab-ci.yml` variables](../yaml/README.md#variables)
+- [Predefined CI/CD variables](../variables/README.md#predefined-cicd-variables)
+- [Project and group CI/CD variables](../variables/README.md)
+- [`.gitlab-ci.yml` CI/CD variables](../yaml/README.md#variables)
 
 However, you cannot use variables defined:
 
@@ -327,7 +327,7 @@ For more information, see [Where variables can be used](../variables/where_varia
 
 #### Example configuration
 
-Runners expose various [environment variables](../variables/README.md) when a job runs, so
+Runners expose various [predefined CI/CD variables](../variables/predefined_variables.md) when a job runs, so
 you can use them as environment names.
 
 In the following example, the job deploys to all branches except `master`:
@@ -825,7 +825,7 @@ build with the specified environment runs. Newer deployments can also
 
 You may want to specify an environment keyword to
 [protect builds from unauthorized access](protected_environments.md), or to get
-access to [scoped variables](#scoping-environments-with-specs). In these cases,
+access to [environment-scoped variables](#scoping-environments-with-specs). In these cases,
 you can use the `action: prepare` keyword to ensure deployments aren't created,
 and no builds are canceled:
 
@@ -846,7 +846,7 @@ build:
 
 As documented in [Configuring dynamic environments](#configuring-dynamic-environments), you can
 prepend environment name with a word, followed by a `/`, and finally the branch
-name, which is automatically defined by the `CI_COMMIT_REF_NAME` variable.
+name, which is automatically defined by the `CI_COMMIT_REF_NAME` predefined CI/CD variable.
 
 In short, environments that are named like `type/foo` are all presented under the same
 group, named `type`.
@@ -1009,9 +1009,9 @@ fetch = +refs/environments/*:refs/remotes/origin/environments/*
 ### Scoping environments with specs
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2112) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.4.
-> - [Scoping for environment variables was moved to Core](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30779) in GitLab 12.2.
+> - [Environment scoping for CI/CD variables was moved to all tiers](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/30779) in GitLab 12.2.
 
-You can limit the environment scope of a variable by
+You can limit the environment scope of a CI/CD variable by
 defining which environments it can be available for.
 
 Wildcards can be used and the default environment scope is `*`. This means that
@@ -1025,7 +1025,7 @@ with `review/` would have that particular variable.
 
 Some GitLab features can behave differently for each environment.
 For example, you can
-[create a secret variable to be injected only into a production environment](../variables/README.md#limit-the-environment-scopes-of-environment-variables).
+[create a secret variable to be injected only into a production environment](../variables/README.md#limit-the-environment-scopes-of-cicd-variables).
 
 In most cases, these features use the _environment specs_ mechanism, which offers
 an efficient way to implement scoping within each environment group.
@@ -1061,7 +1061,7 @@ environment's operational health.
 
 ## Limitations
 
-In the `environment: name`, you are limited to only the [predefined environment variables](../variables/predefined_variables.md).
+In the `environment: name`, you are limited to only the [predefined CI/CD variables](../variables/predefined_variables.md).
 Re-using variables defined inside `script` as part of the environment name doesn't work.
 
 ## Further reading
diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md
index 0e4ad1df65f..2636e59723a 100644
--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: concepts, howto
 ---
 
-# Protected Environments **(PREMIUM)**
+# Protected environments **(PREMIUM)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/6303) in [GitLab Premium](https://about.gitlab.com/pricing/) 11.3.
 
@@ -31,7 +31,7 @@ To protect, update, or unprotect an environment, you need to have at least
 To protect an environment:
 
 1. Navigate to your project's **Settings > CI/CD**.
-1. Expand the **Protected Environments** section.
+1. Expand the **Protected environments** section.
 1. From the **Environment** dropdown menu, select the environment you want to protect.
 1. In the **Allowed to Deploy** dropdown menu, select the role, users, or groups you
    want to give deploy access to. Keep in mind that: