Add latest changes from gitlab-org/gitlab@master

13 files changed, 38 insertions, 37 deletions

diff --git a/doc/api/settings.md b/doc/api/settings.md
index 2fd58917aad..53cb1335a54 100644
--- a/doc/api/settings.md
+++ b/doc/api/settings.md
@@ -305,6 +305,7 @@ listed in the descriptions of the relevant settings.
 | `housekeeping_incremental_repack_period` | integer          | required by: `housekeeping_enabled`  | Number of Git pushes after which an incremental `git repack` is run. |
 | `html_emails_enabled`                    | boolean          | no                                   | Enable HTML emails. |
 | `import_sources`                         | array of strings | no                                   | Sources to allow project import from, possible values: `github`, `bitbucket`, `bitbucket_server`, `gitlab`, `fogbugz`, `git`, `gitlab_project`, `gitea`, `manifest`, and `phabricator`. |
+| `in_product_marketing_emails_enabled`    | boolean          | no                                   | Enable in-product marketing emails. Enabled by default. |
 | `invisible_captcha_enabled`              | boolean          | no                                   | <!-- vale gitlab.Spelling = NO --> Enable Invisible Captcha <!-- vale gitlab.Spelling = YES --> spam detection during sign-up. Disabled by default. |
 | `issues_create_limit`                    | integer          | no                                   | Max number of issue creation requests per minute per user. Disabled by default.|
 | `local_markdown_version`                 | integer          | no                                   | Increase this value when any cached Markdown should be invalidated. |
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 77c63e7ee98..4f4d86d256c 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -355,8 +355,8 @@ You can also store template files in a central repository and `include` them in
 otherwise the external file is not included.
 
 You can't use [YAML anchors](#anchors) across different YAML files sourced by `include`.
-You can only refer to anchors in the same file. Instead of YAML anchors, you can
-use the [`extends` keyword](#extends).
+You can only refer to anchors in the same file. To reuse configuration from different
+YAML files, use [`!reference` tags](#reference-tags) or the [`extends` keyword](#extends).
 
 `include` supports the following inclusion methods:
 
@@ -4391,9 +4391,10 @@ Use anchors to duplicate or inherit properties. Use anchors with [hidden jobs](#
 to provide templates for your jobs. When there are duplicate keys, GitLab
 performs a reverse deep merge based on the keys.
 
-You can't use YAML anchors across multiple files when leveraging the [`include`](#include)
-feature. Anchors are only valid in the file they were defined in. Instead
-of using YAML anchors, you can use the [`extends` keyword](#extends).
+You can't use YAML anchors across multiple files when using the [`include`](#include)
+keyword. Anchors are only valid in the file they were defined in. To reuse configuration
+from different YAML files, use [`!reference` tags](#reference-tags) or the
+[`extends` keyword](#extends).
 
 The following example uses anchors and map merging. It creates two jobs,
 `test1` and `test2`, that inherit the `.job_template` configuration, each
diff --git a/doc/ci/yaml/script.md b/doc/ci/yaml/script.md
index 5750fe1ba61..2dc34777495 100644
--- a/doc/ci/yaml/script.md
+++ b/doc/ci/yaml/script.md
@@ -121,7 +121,7 @@ job:
     - echo -e "\e[31mThis text is red,\e[0m but this text isn't\e[31m however this text is red again."
 ```
 
-You can define the color codes in Shell variables, or even [custom environment variables](../variables/README.md#custom-cicd-variables),
+You can define the color codes in Shell variables, or even [custom CI/CD variables](../variables/README.md#custom-cicd-variables),
 which makes the commands easier to read and reusable.
 
 For example, using the same example as above and variables defined in a `before_script`:
diff --git a/doc/development/usage_ping/dictionary.md b/doc/development/usage_ping/dictionary.md
index 90ef0f254f7..f6894412bf7 100644
--- a/doc/development/usage_ping/dictionary.md
+++ b/doc/development/usage_ping/dictionary.md
@@ -7312,8 +7312,8 @@ Projects with a GitHub service pipeline enabled
 | --- | --- |
 | `key_path` | **`counts.projects_reporting_ci_cd_back_to_github`** |
 | `product_section` | ops |
-| `product_stage` |  |
-| `product_group` | `group::verify` |
+| `product_stage` | verify |
+| `product_group` | `group::continuous_integration` |
 | `product_category` | `continuous_integration` |
 | `value_type` | number |
 | `status` | data_available |
@@ -7321,7 +7321,6 @@ Projects with a GitHub service pipeline enabled
 | `data_source` | Database |
 | `distribution` | ee |
 | `tier` | premium, ultimate |
-| `skip_validation` | true |
 
 ## `counts.projects_slack_active`
 
diff --git a/doc/development/usage_ping/metrics_dictionary.md b/doc/development/usage_ping/metrics_dictionary.md
index db40ce0af27..9f98671050c 100644
--- a/doc/development/usage_ping/metrics_dictionary.md
+++ b/doc/development/usage_ping/metrics_dictionary.md
@@ -28,15 +28,16 @@ Each metric is defined in a separate YAML file consisting of a number of fields:
 |---------------------|----------|----------------------------------------------------------------|
 | `key_path`          | yes      | JSON key path for the metric, location in Usage Ping payload.  |
 | `description`       | yes      |                                                                |
-| `value_type`        | yes      |                                                                |
-| `status`            | yes      |                                                                |
-| `product_group`     | yes      | The [group](https://about.gitlab.com/handbook/product/categories/#devops-stages) that owns the metric. |
-| `time_frame`        | yes      | `string`; may be set to a value like "7d"                             |
-| `data_source`       | yes      | `string`: may be set to a value like `database` or `redis_hll`.       |
+| `product_section`   | yes      | The [section](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/data/sections.yml). |
+| `product_stage`     | no       | The [stage](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) for the metric. |
+| `product_group`     | yes      | The [group](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) that owns the metric. |
+| `product_category`  | no       | The [product category](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml) for the metric. |
+| `value_type`        | yes      | `string`; one of `string`, `number`, `boolean`.                                                               |
+| `status`            | yes      | `string`; status of the metric, may be set to `data_available`, `implemented`. |
+| `time_frame`        | yes      | `string`; may be set to a value like `7d`, `28d`, `all`, `none`. |
+| `data_source`       | yes      | `string`: may be set to a value like `database`, `redis`, `redis_hll`, `prometheus`, `ruby`. |
 | `distribution`      | yes      | The [distribution](https://about.gitlab.com/handbook/marketing/strategic-marketing/tiers/#definitions) where the metric applies. |
 | `tier`              | yes      | The [tier]( https://about.gitlab.com/handbook/marketing/strategic-marketing/tiers/) where the metric applies. |
-| `product_category`  | no       | The [product category](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/categories.yml) for the metric. |
-| `product_stage`     | no       | The [stage](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/stages.yml) for the metric. |
 | `milestone`         | no       | The milestone when the metric is introduced. |
 | `milestone_removed` | no       | The milestone when the metric is removed. |
 | `introduced_by_url` | no       | The URL to the Merge Request that introduced the metric. |
diff --git a/doc/user/infrastructure/terraform_state.md b/doc/user/infrastructure/terraform_state.md
index 786665ec47c..2cd5ed8ac78 100644
--- a/doc/user/infrastructure/terraform_state.md
+++ b/doc/user/infrastructure/terraform_state.md
@@ -116,7 +116,7 @@ and the CI YAML file:
    image: registry.gitlab.com/gitlab-org/terraform-images/stable:latest
    ```
 
-1. In the `.gitlab-ci.yml` file, define some environment variables to ease
+1. In the `.gitlab-ci.yml` file, define some CI/CD variables to ease
    development. In this example, `TF_ROOT` is the directory where the Terraform
    commands must be executed, `TF_ADDRESS` is the URL to the state on the GitLab
    instance where this pipeline runs, and the final path segment in `TF_ADDRESS`
@@ -212,7 +212,7 @@ as [Terraform input variables](https://www.terraform.io/docs/language/values/var
 - **username**: The username to authenticate with the data source. If you are using a [Personal Access Token](../profile/personal_access_tokens.md) for
   authentication, this is your GitLab username. If you are using GitLab CI, this is `'gitlab-ci-token'`.
 - **password**: The password to authenticate with the data source. If you are using a Personal Access Token for
-  authentication, this is the token value. If you are using GitLab CI, it is the contents of the `${CI_JOB_TOKEN}` CI variable.
+  authentication, this is the token value. If you are using GitLab CI, it is the contents of the `${CI_JOB_TOKEN}` CI/CD variable.
 
 An example setup is shown below:
 
diff --git a/doc/user/project/clusters/index.md b/doc/user/project/clusters/index.md
index fd3426f01e2..69e0c547f7d 100644
--- a/doc/user/project/clusters/index.md
+++ b/doc/user/project/clusters/index.md
@@ -86,7 +86,7 @@ differentiates the new cluster from the rest.
 
 When adding more than one Kubernetes cluster to your project, you need to differentiate
 them with an environment scope. The environment scope associates clusters with [environments](../../../ci/environments/index.md) similar to how the
-[environment-specific variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables) work.
+[environment-specific CI/CD variables](../../../ci/variables/README.md#limit-the-environment-scopes-of-cicd-variables) work.
 
 The default environment scope is `*`, which means all jobs, regardless of their
 environment, use that cluster. Each scope can be used only by a single cluster
@@ -200,7 +200,7 @@ To clear the cache:
 You do not need to specify a base domain on cluster settings when using GitLab Serverless. The domain in that case
 is specified as part of the Knative installation. See [Installing Applications](#installing-applications).
 
-Specifying a base domain automatically sets `KUBE_INGRESS_BASE_DOMAIN` as an environment variable.
+Specifying a base domain automatically sets `KUBE_INGRESS_BASE_DOMAIN` as an deployment variable.
 If you are using [Auto DevOps](../../../topics/autodevops/index.md), this domain is used for the different
 stages. For example, Auto Review Apps and Auto Deploy.
 
@@ -288,7 +288,7 @@ A Kubernetes cluster can be the destination for a deployment job. If
   the cluster from your jobs using tools such as `kubectl` or `helm`.
 - You don't use the GitLab cluster integration, you can still deploy to your
   cluster. However, you must configure Kubernetes tools yourself
-  using [environment variables](../../../ci/variables/README.md#custom-cicd-variables)
+  using [CI/CD variables](../../../ci/variables/README.md#custom-cicd-variables)
   before you can interact with the cluster from your jobs.
 
 ### Deployment variables
@@ -314,7 +314,7 @@ The Kubernetes cluster integration exposes these
 GitLab CI/CD build environment to deployment jobs. Deployment jobs have
 [defined a target environment](../../../ci/environments/index.md#defining-environments).
 
-| Variable                   | Description |
+| Deployment Variable        | Description |
 |----------------------------|-------------|
 | `KUBE_URL`                 | Equal to the API URL. |
 | `KUBE_TOKEN`               | The Kubernetes token of the [environment service account](add_remove_clusters.md#access-controls). Prior to GitLab 11.5, `KUBE_TOKEN` was the Kubernetes token of the main service account of the cluster integration. |
@@ -352,7 +352,7 @@ When you customize the namespace, existing environments remain linked to their c
 namespaces until you [clear the cluster cache](#clearing-the-cluster-cache).
 
 WARNING:
-By default, anyone who can create a deployment job can access any CI variable in
+By default, anyone who can create a deployment job can access any CI/CD variable in
 an environment's deployment job. This includes `KUBECONFIG`, which gives access to
 any secret available to the associated service account in your cluster.
 To keep your production credentials safe, consider using
@@ -406,7 +406,7 @@ deployments, replica sets, and pods are annotated with:
 - `app.gitlab.com/app: $CI_PROJECT_PATH_SLUG`
 
 `$CI_ENVIRONMENT_SLUG` and `$CI_PROJECT_PATH_SLUG` are the values of
-the CI variables.
+the CI/CD variables.
 
 You must be the project owner or have `maintainer` permissions to use terminals.
 Support is limited to the first container in the first pod of your environment.
@@ -431,7 +431,7 @@ Reasons for failure include:
 
 - The token you gave GitLab does not have [`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
   privileges required by GitLab.
-- Missing `KUBECONFIG` or `KUBE_TOKEN` variables. To be passed to your job, they must have a matching
+- Missing `KUBECONFIG` or `KUBE_TOKEN` deployment variables. To be passed to your job, they must have a matching
   [`environment:name`](../../../ci/environments/index.md#defining-environments). If your job has no
   `environment:name` set, the Kubernetes credentials are not passed to it.
 
diff --git a/doc/user/project/clusters/serverless/aws.md b/doc/user/project/clusters/serverless/aws.md
index 192a7c7cd39..992d28a351d 100644
--- a/doc/user/project/clusters/serverless/aws.md
+++ b/doc/user/project/clusters/serverless/aws.md
@@ -367,8 +367,7 @@ sam init -h
 ### Setting up your AWS credentials with your GitLab account
 
 In order to interact with your AWS account, the GitLab CI/CD pipelines require both
-`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD
-variables.
+`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD variables.
 
 To set these:
 
@@ -424,8 +423,8 @@ deploys your application. If your:
   - Incompatible versions of software. For example, Python runtime version might be
     different from the Python on the build machine. Address this by installing the
     required versions of the software.
-  - You may not be able to access your AWS account from GitLab. Check the environment
-    variables you set up with AWS credentials.
+  - You may not be able to access your AWS account from GitLab. Check the CI/CD variables
+    you set up with AWS credentials.
   - You may not have permission to deploy a serverless application. Make sure you
     provide all required permissions to deploy a serverless application.
 
diff --git a/doc/user/project/clusters/serverless/index.md b/doc/user/project/clusters/serverless/index.md
index c7ed8d6d2a5..fca34c24e8f 100644
--- a/doc/user/project/clusters/serverless/index.md
+++ b/doc/user/project/clusters/serverless/index.md
@@ -396,7 +396,7 @@ kubectl create secret generic my-secrets -n "$KUBE_NAMESPACE" --from-literal MY_
 
 #### Part of deployment job
 
-You can extend your `.gitlab-ci.yml` to create the secrets during deployment using the [environment variables](../../../../ci/variables/README.md)
+You can extend your `.gitlab-ci.yml` to create the secrets during deployment using the [CI/CD variables](../../../../ci/variables/README.md)
 stored securely under your GitLab project.
 
 ```yaml
diff --git a/doc/user/project/deploy_boards.md b/doc/user/project/deploy_boards.md
index 83e3d0c2c80..01d2be47129 100644
--- a/doc/user/project/deploy_boards.md
+++ b/doc/user/project/deploy_boards.md
@@ -90,7 +90,7 @@ To display the Deploy Boards for a specific [environment](../../ci/environments/
    [`kubernetes`](https://docs.gitlab.com/runner/executors/kubernetes.html) executor.
 1. Configure the [Kubernetes integration](clusters/index.md) in your project for the
    cluster. The Kubernetes namespace is of particular note as you need it
-   for your deployment scripts (exposed by the `KUBE_NAMESPACE` environment variable).
+   for your deployment scripts (exposed by the `KUBE_NAMESPACE` deployment variable).
 1. Ensure Kubernetes annotations of `app.gitlab.com/env: $CI_ENVIRONMENT_SLUG`
    and `app.gitlab.com/app: $CI_PROJECT_PATH_SLUG` are applied to the
    deployments, replica sets, and pods, where `$CI_ENVIRONMENT_SLUG` and
@@ -163,6 +163,6 @@ version of your application.
 ## Further reading
 
 - [GitLab Auto deploy](../../topics/autodevops/stages.md#auto-deploy)
-- [GitLab CI/CD environment variables](../../ci/variables/README.md)
+- [GitLab CI/CD variables](../../ci/variables/README.md)
 - [Environments and deployments](../../ci/environments/index.md)
 - [Kubernetes deploy example](https://gitlab.com/gitlab-examples/kubernetes-deploy)
diff --git a/doc/user/project/deploy_tokens/index.md b/doc/user/project/deploy_tokens/index.md
index 2eb9bdf0c2a..1797a0bf41d 100644
--- a/doc/user/project/deploy_tokens/index.md
+++ b/doc/user/project/deploy_tokens/index.md
@@ -169,7 +169,7 @@ apply consistently when cloning the repository of related projects.
 
 There's a special case when it comes to Deploy Tokens. If a user creates one
 named `gitlab-deploy-token`, the username and token of the Deploy Token is
-automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER`
+automatically exposed to the CI/CD jobs as CI/CD variables: `CI_DEPLOY_USER`
 and `CI_DEPLOY_PASSWORD`, respectively.
 
 After you create the token, you can sign in to the Container Registry by using
diff --git a/doc/user/project/push_options.md b/doc/user/project/push_options.md
index f94a4075363..59e915dd9e6 100644
--- a/doc/user/project/push_options.md
+++ b/doc/user/project/push_options.md
@@ -34,12 +34,12 @@ git push -o <push_option>
 
 ## Push options for GitLab CI/CD
 
-You can use push options to skip a CI/CD pipeline, or pass environment variables.
+You can use push options to skip a CI/CD pipeline, or pass CI/CD variables.
 
 | Push option                    | Description                                                                                 | Introduced in version |
 | ------------------------------ | ------------------------------------------------------------------------------------------- |---------------------- |
 | `ci.skip`                      | Do not create a CI pipeline for the latest push.                                            | [11.7](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15643) |
-| `ci.variable="<name>=<value>"` | Provide [environment variables](../../ci/variables/README.md) to be used in a CI pipeline, if one is created due to the push. | [12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/27983) |
+| `ci.variable="<name>=<value>"` | Provide [CI/CD variables](../../ci/variables/README.md) to be used in a CI pipeline, if one is created due to the push. | [12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/27983) |
 
 An example of using `ci.skip`:
 
@@ -47,7 +47,7 @@ An example of using `ci.skip`:
 git push -o ci.skip
 ```
 
-An example of passing some environment variables for a pipeline:
+An example of passing some CI/CD variables for a pipeline:
 
 ```shell
 git push -o ci.variable="MAX_RETRIES=10" -o ci.variable="MAX_TIME=600"
diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md
index 5345a031c48..55f470251dc 100644
--- a/doc/user/project/web_ide/index.md
+++ b/doc/user/project/web_ide/index.md
@@ -421,7 +421,7 @@ terminal:
   See [this issue](https://gitlab.com/gitlab-org/webide-file-sync/-/issues/7) for
   more information.
 - `$CI_PROJECT_DIR` is a
-  [predefined environment variable](../../../ci/variables/predefined_variables.md)
+  [predefined CI/CD variable](../../../ci/variables/predefined_variables.md)
   for GitLab Runners. This is where your project's repository resides.
 
 After you have configured the web terminal for file syncing, then when the web