Add latest changes from gitlab-org/gitlab@master

12 files changed, 54 insertions, 54 deletions

diff --git a/doc/user/application_security/cluster_image_scanning/index.md b/doc/user/application_security/cluster_image_scanning/index.md
index 8b29da06b57..8bf0efd5261 100644
--- a/doc/user/application_security/cluster_image_scanning/index.md
+++ b/doc/user/application_security/cluster_image_scanning/index.md
@@ -29,7 +29,7 @@ To integrate GitLab with security scanners other than those listed here, see
 You can use cluster image scanning through the following methods:
 
 - [The cluster image scanning analyzer](#use-the-cluster-image-scanning-analyzer)
-- [The GitLab Agent](#cluster-image-scanning-with-the-gitlab-agent)
+- [The GitLab agent](#cluster-image-scanning-with-the-gitlab-agent)
 
 ## Use the cluster image scanning analyzer
 
@@ -277,22 +277,22 @@ Here's an example cluster image scanning report:
 }
 ```
 
-## Cluster image scanning with the GitLab Agent
+## Cluster image scanning with the GitLab agent
 
-You can use the [GitLab Agent](../../clusters/agent/index.md) to
+You can use the [GitLab agent](../../clusters/agent/index.md) to
 scan images from within your Kubernetes cluster and record the vulnerabilities in GitLab.
 
 ### Prerequisites
 
 - [Starboard Operator](https://aquasecurity.github.io/starboard/v0.10.3/operator/installation/kubectl/)
   installed and configured in your cluster.
-- [GitLab Agent](../../clusters/agent/install/index.md)
+- [GitLab agent](../../clusters/agent/install/index.md)
   set up in GitLab, installed in your cluster, and configured using a configuration repository.
 
 ### Configuration
 
-The Agent runs the cluster image scanning once the `cluster_image_scanning`
-directive is added to your [Agent's configuration repository](../../clusters/agent/vulnerabilities.md).
+The agent runs the cluster image scanning once the `cluster_image_scanning`
+directive is added to your [agent's configuration repository](../../clusters/agent/vulnerabilities.md).
 
 ## Security Dashboard
 
@@ -302,7 +302,7 @@ the security vulnerabilities in your groups, projects, and pipelines.
 ## Interacting with the vulnerabilities
 
 After you find a vulnerability, you can address it in the [vulnerability report](../vulnerabilities/index.md)
-or the [GitLab Agent's](../../clusters/agent/vulnerabilities.md)
+or the [GitLab agent's](../../clusters/agent/vulnerabilities.md)
 details section.
 
 ## Troubleshooting
diff --git a/doc/user/clusters/agent/index.md b/doc/user/clusters/agent/index.md
index bf7ec9c2a4e..6d3151434cc 100644
--- a/doc/user/clusters/agent/index.md
+++ b/doc/user/clusters/agent/index.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223061) in GitLab 13.4.
 > - Support for `grpcs` [introduced](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/issues/7) in GitLab 13.6.
-> - Agent Server [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300960) on GitLab.com under `wss://kas.gitlab.com` through an Early Adopter Program in GitLab 13.10.
+> - Agent server [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/300960) on GitLab.com under `wss://kas.gitlab.com` through an Early Adopter Program in GitLab 13.10.
 > - The agent became available to every project on GitLab.com in GitLab 13.11.
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) from GitLab Premium to GitLab Free in 14.5.
 > - [Renamed](https://gitlab.com/groups/gitlab-org/-/epics/7167) from "GitLab Kubernetes Agent" to "GitLab agent for Kubernetes" in GitLab 14.6.
diff --git a/doc/user/clusters/agent/repository.md b/doc/user/clusters/agent/repository.md
index bf778cc0fdc..11555f368da 100644
--- a/doc/user/clusters/agent/repository.md
+++ b/doc/user/clusters/agent/repository.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Working with the agent for Kubernetes **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7.
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.11, the GitLab Agent became available on GitLab.com.
+> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3834) in GitLab 13.11, the GitLab agent became available on GitLab.com.
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/5784) the `ci_access` attribute in GitLab 14.3.
 > - [Moved](https://gitlab.com/groups/gitlab-org/-/epics/6290) from GitLab Premium to GitLab Free in 14.5.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332227) in GitLab 14.0, the `resource_inclusions` and `resource_exclusions` attributes were removed and `reconcile_timeout`, `dry_run_strategy`, `prune`, `prune_timeout`, `prune_propagation_policy`, and `inventory_policy` attributes were added.
diff --git a/doc/user/clusters/agent/troubleshooting.md b/doc/user/clusters/agent/troubleshooting.md
index 2fcf0c9aa98..a5e568837ad 100644
--- a/doc/user/clusters/agent/troubleshooting.md
+++ b/doc/user/clusters/agent/troubleshooting.md
@@ -4,9 +4,9 @@ group: Configure
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Troubleshooting the GitLab Agent for Kubernetes
+# Troubleshooting the GitLab agent for Kubernetes
 
-When you are using the GitLab Agent for Kubernetes, you might experience issues you need to troubleshoot.
+When you are using the GitLab agent for Kubernetes, you might experience issues you need to troubleshoot.
 
 You can start by viewing the service logs:
 
@@ -14,7 +14,7 @@ You can start by viewing the service logs:
 kubectl logs -f -l=app=gitlab-agent -n gitlab-kubernetes-agent
 ```
 
-If you are a GitLab administrator, you can also view the [GitLab Agent Server logs](../../../administration/clusters/kas.md#troubleshooting).
+If you are a GitLab administrator, you can also view the [GitLab agent server logs](../../../administration/clusters/kas.md#troubleshooting).
 
 ## Transport: Error while dialing failed to WebSocket dial
 
@@ -28,7 +28,7 @@ If you are a GitLab administrator, you can also view the [GitLab Agent Server lo
 ```
 
 This error is shown if there are some connectivity issues between the address
-specified as `kas-address`, and your Agent pod. To fix it, make sure that you
+specified as `kas-address`, and your agent pod. To fix it, make sure that you
 specified the `kas-address` correctly.
 
 ```json
@@ -189,4 +189,4 @@ Alternatively, you can mount the certificate file at a different location and in
 ```
 
 This error is shown if the manifest project is not public. To fix it, make sure your manifest project is public or your manifest files
-are stored in the Agent's configuration repository.
+are stored in the agent's configuration repository.
diff --git a/doc/user/clusters/integrations.md b/doc/user/clusters/integrations.md
index ee7452537fd..43a35177d28 100644
--- a/doc/user/clusters/integrations.md
+++ b/doc/user/clusters/integrations.md
@@ -32,9 +32,9 @@ to automate this step.
 
 Prometheus and Elastic Stack cluster integrations can only be enabled for clusters [connected through cluster certificates](../project/clusters/add_existing_cluster.md).
 
-To enable Prometheus for your cluster connected through the [GitLab Agent](agent/index.md), you can [integrate it manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
+To enable Prometheus for your cluster connected through the [GitLab agent](agent/index.md), you can [integrate it manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
 
-There is no option to enable Elastic Stack for your cluster if it is connected with the GitLab Agent.
+There is no option to enable Elastic Stack for your cluster if it is connected with the GitLab agent.
 Follow this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300230) for updates.
 
 ## Prometheus cluster integration
@@ -44,7 +44,7 @@ Follow this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/300230) for up
 WARNING:
 This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. However, you can **still use** Prometheus
 for Kubernetes clusters connected to GitLab through the
-[Agent](agent/index.md) by [enabling Prometheus manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
+[agent](agent/index.md) by [enabling Prometheus manually](../project/integrations/prometheus.md#manual-configuration-of-prometheus).
 
 You can integrate your Kubernetes cluster with
 [Prometheus](https://prometheus.io/) for monitoring key metrics of your
diff --git a/doc/user/clusters/management_project.md b/doc/user/clusters/management_project.md
index e28f9275b50..7658bc41dd9 100644
--- a/doc/user/clusters/management_project.md
+++ b/doc/user/clusters/management_project.md
@@ -11,7 +11,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 WARNING:
 The cluster management project was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
-To manage cluster applications, use the [GitLab Agent](agent/index.md)
+To manage cluster applications, use the [GitLab agent](agent/index.md)
 with the [Cluster Management Project Template](management_project_template.md).
 
 A project can be designated as the management project for a cluster.
diff --git a/doc/user/clusters/management_project_template.md b/doc/user/clusters/management_project_template.md
index af82c166dcb..93af5849fcb 100644
--- a/doc/user/clusters/management_project_template.md
+++ b/doc/user/clusters/management_project_template.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25318) in GitLab 12.10 with Helmfile support via Helm v2.
 > - Helm v2 support was [dropped](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63577) in GitLab 14.0. Use Helm v3 instead.
-> - [Migrated](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/24) to the GitLab Agent in GitLab 14.5.
+> - [Migrated](https://gitlab.com/gitlab-org/project-templates/cluster-management/-/merge_requests/24) to the GitLab agent in GitLab 14.5.
 
 Use a repository to install, manage, and deploy clusters applications through code.
 
@@ -31,45 +31,45 @@ you can manage cluster applications with [Helm v3](https://helm.sh/).
 - An `applications` directory with a `helmfile.yaml` configured for each
 application available in the template.
 
-## Use the Agent with the Cluster Management Project Template
+## Use the agent with the Cluster Management Project Template
 
 To use a new project created from the Cluster Management Project Template
-with a cluster connected to GitLab through the [GitLab Agent](agent/index.md),
+with a cluster connected to GitLab through the [GitLab agent](agent/index.md),
 you have two options:
 
-- [Use one single project](#single-project) to configure the Agent and manage cluster applications.
-- [Use separate projects](#separate-projects) - one to configure the Agent and another to manage cluster applications.
+- [Use one single project](#single-project) to configure the agent and manage cluster applications.
+- [Use separate projects](#separate-projects) - one to configure the agent and another to manage cluster applications.
 
 ### Single project
 
 This setup is particularly useful when you haven't connected your cluster
-to GitLab through the Agent yet and you want to use the Cluster Management
+to GitLab through the agent yet and you want to use the Cluster Management
 Project Template to manage cluster applications.
 
-To use one single project to configure the Agent and to manage cluster applications:
+To use one single project to configure the agent and to manage cluster applications:
 
 1. [Create a new project from the Cluster Management Project Template](#create-a-new-project-based-on-the-cluster-management-template).
-1. Configure the new project as the [Agent's configuration repository](agent/repository.md)
-(where the Agent is registered and its `config.yaml` is stored).
+1. Configure the new project as the [agent's configuration repository](agent/repository.md)
+(where the agent is registered and its `config.yaml` is stored).
 1. From your project's settings, add a [new environment variable](../../ci/variables/index.md#add-a-cicd-variable-to-a-project) `$KUBE_CONTEXT` and set it to `path/to/agent-configuration-project:your-agent-name`.
 1. [Configure the components](#configure-the-available-components) inherited from the template.
 
 ### Separate projects
 
 This setup is particularly useful **when you already have a cluster** connected
-to GitLab through the Agent and want to use the Cluster Management
+to GitLab through the agent and want to use the Cluster Management
 Project Template to manage cluster applications.
 
-To use one project to configure the Agent ("project A") and another project to
+To use one project to configure the agent ("project A") and another project to
 manage cluster applications ("project B"), follow the steps below.
 
-We assume that you already have a cluster connected through the Agent and
-[configured through the Agent's configuration repository](agent/repository.md)
+We assume that you already have a cluster connected through the agent and
+[configured through the agent's configuration repository](agent/repository.md)
 ("project A").
 
 1. [Create a new project from the Cluster Management Project Template](#create-a-new-project-based-on-the-cluster-management-template).
 This new project is "project B".
-1. In your "project A", [grant the Agent access to the new project (B) through the CI/CD Tunnel](agent/ci_cd_tunnel.md#authorize-the-agent).
+1. In your "project A", [grant the agent access to the new project (B) through the CI/CD Tunnel](agent/ci_cd_tunnel.md#authorize-the-agent).
 1. From the "project's B" settings, add a [new environment variable](../../ci/variables/index.md#add-a-cicd-variable-to-a-project) `$KUBE_CONTEXT` and set it to `path/to/agent-configuration-project:your-agent-name`.
 1. In "project B", [configure the components](#configure-the-available-components) inherited from the template.
 
diff --git a/doc/user/group/clusters/index.md b/doc/user/group/clusters/index.md
index b2b16321488..0da7eaa4d55 100644
--- a/doc/user/group/clusters/index.md
+++ b/doc/user/group/clusters/index.md
@@ -12,7 +12,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 WARNING:
 This feature was [deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5. To connect clusters to GitLab,
-use the [GitLab Agent](../../clusters/agent/index.md).
+use the [GitLab agent](../../clusters/agent/index.md).
 
 Similar to [project-level](../../project/clusters/index.md) and
 [instance-level](../../instance/clusters/index.md) Kubernetes clusters,
diff --git a/doc/user/group/roadmap/index.md b/doc/user/group/roadmap/index.md
index f10dc3bc22a..64cead7642f 100644
--- a/doc/user/group/roadmap/index.md
+++ b/doc/user/group/roadmap/index.md
@@ -24,12 +24,12 @@ When you hover over an epic bar, a popover appears with the epic's title, start
 weight completed.
 
 You can expand epics that contain child epics to show their child epics in the roadmap.
-You can click the chevron (**{chevron-down}**) next to the epic title to expand and collapse the
+You can select the chevron (**{chevron-down}**) next to the epic title to expand and collapse the
 child epics.
 
 On top of the milestone bars, you can see their title.
 When you hover over a milestone bar or title, a popover appears with its title, start date, and due
-date. You can also click the chevron (**{chevron-down}**) next to the **Milestones** heading to
+date. You can also select the chevron (**{chevron-down}**) next to the **Milestones** heading to
 toggle the list of the milestone bars.
 
 ![roadmap view](img/roadmap_view_v14_3.png)
@@ -47,9 +47,9 @@ Filtering roadmaps by milestone might not be available to you. Check the **versi
 When you want to explore a roadmap, there are several ways to make it easier by sorting epics or
 filtering them by what's important for you.
 
-A dropdown menu lets you show only open or closed epics. By default, all epics are shown.
+A dropdown list lets you show only open or closed epics. By default, all epics are shown.
 
-![epics state dropdown](img/epics_state_dropdown_v14_3.png)
+![epics state dropdown list](img/epics_state_dropdown_v14_3.png)
 
 You can sort epics in the Roadmap view by:
 
@@ -85,7 +85,7 @@ When you enable the roadmap settings sidebar, you can use it to refine epics sho
 You can configure the following:
 
 - Select date range.
-- Turn milestones on or off and select whether to show all, group, sub-group, or project milestones.
+- Turn milestones on or off and select whether to show all, group, subgroup, or project milestones.
 - Show all, open, or closed epics.
 - Turn progress tracking for child issues on or off and select whether
   to use issue weights or counts.
diff --git a/doc/user/infrastructure/clusters/index.md b/doc/user/infrastructure/clusters/index.md
index 06122b85c98..5f9cc2e2f5f 100644
--- a/doc/user/infrastructure/clusters/index.md
+++ b/doc/user/infrastructure/clusters/index.md
@@ -6,7 +6,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Kubernetes clusters **(FREE)**
 
-To connect clusters to GitLab, use the [GitLab Agent](../../clusters/agent/index.md).
+To connect clusters to GitLab, use the [GitLab agent](../../clusters/agent/index.md).
 
 ## Certificate-based Kubernetes integration (DEPRECATED)
 
@@ -24,7 +24,7 @@ It had the following issues:
 - Users were constantly reporting issues with features based on this model.
 
 For this reason, we started to build features based on a new model, the
-[GitLab Agent](../../clusters/agent/index.md).
+[GitLab agent](../../clusters/agent/index.md).
 Maintaining both methods in parallel caused a lot of confusion
 and significantly increased the complexity to use, develop, maintain, and
 document them. For this reason, we decided to deprecate them to focus on the
@@ -38,7 +38,7 @@ Follow this [epic](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)
 for updates.
 
 You can find technical information about why we moved away from cluster certificates into
-the GitLab Agent model on the [Agent's blueprint documentation](../../../architecture/blueprints/gitlab_to_kubernetes_communication/index.md).
+the GitLab agent model on the [agent's blueprint documentation](../../../architecture/blueprints/gitlab_to_kubernetes_communication/index.md).
 
 ## Deprecated features
 
@@ -67,6 +67,6 @@ The concept of [project-level](../../project/clusters/index.md),
 [instance-level](../../instance/clusters/index.md) clusters becomes
 extinct in the new model, although the functionality remains to some extent.
 
-The Agent is always configured in a single GitLab project, but you can use the CI/CD Tunnel to
-authorize other projects and groups to use the same Agent.
+The agent is always configured in a single GitLab project, but you can use the CI/CD Tunnel to
+authorize other projects and groups to use the same agent.
 By doing so, you are granting these projects and groups access to the same cluster, which is similar to group-level clusters' use case.
diff --git a/doc/user/infrastructure/index.md b/doc/user/infrastructure/index.md
index d8e75928675..73e57ea3d59 100644
--- a/doc/user/infrastructure/index.md
+++ b/doc/user/infrastructure/index.md
@@ -30,11 +30,11 @@ Learn more about how GitLab can help you run [Infrastructure as Code](iac/index.
 ## Integrated Kubernetes management
 
 The GitLab integration with Kubernetes helps you to install, configure, manage, deploy, and troubleshoot
-cluster applications. With the GitLab Agent, you can connect clusters behind a firewall,
+cluster applications. With the GitLab agent, you can connect clusters behind a firewall,
 have real-time access to API endpoints, perform pull-based or push-based deployments for production
 and non-production environments, and much more.
 
-Learn more about the [GitLab Agent](../clusters/agent/index.md).
+Learn more about the [GitLab agent](../clusters/agent/index.md).
 
 ## Runbooks in GitLab
 
diff --git a/doc/user/project/canary_deployments.md b/doc/user/project/canary_deployments.md
index 77cf04cc7eb..0e60d0d88bc 100644
--- a/doc/user/project/canary_deployments.md
+++ b/doc/user/project/canary_deployments.md
@@ -35,7 +35,7 @@ your pods fleet and watch their behavior as a percentage of your user base
 visits the temporarily deployed feature. If all works well, you can deploy the
 feature to production knowing that it shouldn't cause any problems.
 
-Canary deployments are also especially useful for backend refactors, performance
+Canary deployments are also especially required for backend refactors, performance
 improvements, or other changes where the user interface doesn't change, but you
 want to make sure the performance stays the same, or improves. Developers need
 to be careful when using canaries with user-facing changes, because by default,
@@ -50,7 +50,7 @@ this document.
 Canary deployments require that you properly configure deploy boards:
 
 1. Follow the steps to [enable deploy boards](deploy_boards.md#enabling-deploy-boards).
-1. To track canary deployments you need to label your Kubernetes deployments and
+1. To track canary deployments you must label your Kubernetes deployments and
    pods with `track: canary`. To get started quickly, you can use the [Auto Deploy](../../topics/autodevops/stages.md#auto-deploy)
    template for canary deployments that GitLab provides.
 
@@ -60,12 +60,12 @@ Any other track label is considered `canary` (temporary).
 This allows GitLab to discover whether a deployment is stable or canary (temporary).
 
 Once all of the above are set up and the pipeline has run at least once,
-navigate to the environments page under **Pipelines > Environments**.
+Go to the environments page under **Pipelines > Environments**.
 As the pipeline executes, deploy boards clearly mark canary pods, enabling
-quick and easy insight into the status of each environment and deployment.
+quick and clear insight into the status of each environment and deployment.
 
 Canary deployments are marked with a yellow dot in the deploy board so that you
-can easily notice them.
+can quickly notice them.
 
 ![Canary deployments on deploy board](img/deploy_boards_canary_deployments.png)
 
@@ -82,7 +82,7 @@ Canary deployments can be more strategic with [Canary Ingress](https://kubernete
 which is an advanced traffic routing service that controls incoming HTTP
 requests between stable and canary deployments based on factors such as weight, sessions, cookies,
 and others. GitLab uses this service in its [Auto Deploy architecture](../../topics/autodevops/upgrading_auto_deploy_dependencies.md#v2-chart-resource-architecture)
-to let users easily and safely roll out their new deployments.
+to let users quickly and safely roll out their new deployments.
 
 #### How to set up a Canary Ingress in a canary deployment
 
@@ -115,13 +115,13 @@ Here's an example setup flow from scratch:
 
 #### How to change the traffic weight on a Canary Ingress
 
-You can change the traffic weight within your environment's deploy board by using [GraphiQL](../../api/graphql/getting_started.md#graphiql),
+You can change the traffic weight in your environment's deploy board by using [GraphiQL](../../api/graphql/getting_started.md#graphiql),
 or by sending requests to the [GraphQL API](../../api/graphql/getting_started.md#command-line).
 
 To use your [deploy board](../../user/project/deploy_boards.md):
 
-1. Navigate to **Deployments > Environments** for your project.
-1. Set the new weight with the dropdown on the right side.
+1. Go to **Deployments > Environments** for your project.
+1. Set the new weight with the dropdown list on the right side.
 1. Confirm your selection.
 
 Here's an example using [GraphiQL](../../api/graphql/getting_started.md#graphiql):