Remove more inline icons

doc/administration/geo/disaster_recovery/background_verification.md

@@ -141,7 +141,7 @@ sudo gitlab-rake geo:verification:wiki:reset
 
 If the **primary** and **secondary** nodes have a checksum verification mismatch, the cause may not be apparent. To find the cause of a checksum mismatch:
 
-1. Navigate to the **Admin Area >** **{overview}** **Overview > Projects** dashboard on the **primary** node, find the
+1. Navigate to the **Admin Area > Overview > Projects** dashboard on the **primary** node, find the
    project that you want to check the checksum differences and click on the
    **Edit** button:
    ![Projects dashboard](img/checksum-differences-admin-projects.png)

doc/administration/geo/disaster_recovery/planned_failover.md

@@ -135,7 +135,7 @@ This [content was moved to another location](background_verification.md).
 
 ### Notify users of scheduled maintenance
 
-On the **primary** node, navigate to **Admin Area >** **{bullhorn}** **Messages**, add a broadcast
+On the **primary** node, navigate to **Admin Area > Messages**, add a broadcast
 message. You can check under **Admin Area > Geo** to estimate how long it
 will take to finish syncing. An example message would be:
 
@@ -181,7 +181,7 @@ access to the **primary** node during the maintenance window.
    connection.
 
 1. Disable non-Geo periodic background jobs on the **primary** node by navigating
-   to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Cron**, pressing `Disable All`,
+   to **Admin Area > Monitoring > Background Jobs > Cron**, pressing `Disable All`,
    and then pressing `Enable` for the `geo_sidekiq_cron_config_worker` cron job.
    This job will re-enable several other cron jobs that are essential for planned
    failover to complete successfully.
@@ -190,7 +190,7 @@ access to the **primary** node during the maintenance window.
 
 1. If you are manually replicating any data not managed by Geo, trigger the
    final replication process now.
-1. On the **primary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
+1. On the **primary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
    and wait for all queues except those with `geo` in the name to drop to 0.
    These queues contain work that has been submitted by your users; failing over
    before it is completed will cause the work to be lost.
@@ -202,7 +202,7 @@ access to the **primary** node during the maintenance window.
    - Database replication lag is 0ms.
    - The Geo log cursor is up to date (0 events behind).
 
-1. On the **secondary** node, navigate to **Admin Area >** **{monitor}** **Monitoring > Background Jobs > Queues**
+1. On the **secondary** node, navigate to **Admin Area > Monitoring > Background Jobs > Queues**
    and wait for all the `geo` queues to drop to 0 queued and 0 running jobs.
 1. On the **secondary** node, use [these instructions](../../raketasks/check.md)
    to verify the integrity of CI artifacts, LFS objects, and uploads in file

doc/administration/monitoring/performance/request_profiling.md

@@ -10,7 +10,7 @@ To profile a request:
 
 1. Sign in to GitLab as a user with Administrator or Maintainer [permissions](../../../user/permissions.md).
 1. In the navigation bar, click **Admin area**.
-1. Navigate to **{monitor}** **Monitoring > Requests Profiles**.
+1. Navigate to **Monitoring > Requests Profiles**.
 1. In the **Requests Profiles** section, copy the token.
 1. Pass the headers `X-Profile-Token: <token>` and `X-Profile-Mode: <mode>`(where
    `<mode>` can be `execution` or `memory`) to the request you want to profile. When
@@ -29,7 +29,7 @@ To profile a request:
      Profiled requests can take longer than usual.
 
 After the request completes, you can view the profiling output from the
-**{monitor}** **Monitoring > Requests Profiles** administration page:
+**Monitoring > Requests Profiles** administration page:
 
 ![Profiling output](img/request_profile_result.png)
 

doc/operations/incident_management/index.md

@@ -15,7 +15,7 @@ of incident management are only available in
 [GitLab Ultimate and GitLab.com Gold](https://about.gitlab.com/pricing/).
 
 For users with at least Developer [permissions](../../user/permissions.md), the
-Incident Management list is available at **{cloud-gear}** **Operations > Incidents**
+Incident Management list is available at **Operations > Incidents**
 in your project's sidebar. The list contains the following metrics:
 
 ![Incident Management List](img/incident_list_13_3.png)
@@ -36,7 +36,7 @@ Incidents share the [Issues API](../../user/project/issues/index.md).
 
 To create a Incident you can take any of the following actions:
 
-- Navigate to **{cloud-gear}** **Operations > Incidents** and click **Create Incident**.
+- Navigate to **Operations > Incidents** and click **Create Incident**.
 - Create a new issue using the `incident` template available when creating it.
 - Create a new issue and assign the `incident` label to it.
 

doc/operations/metrics/alerts.md

@@ -19,7 +19,7 @@ For managed Prometheus instances using auto configuration, you can
 [configure alerts for metrics](index.md#adding-custom-metrics) directly in the
 [metrics dashboard](index.md). To set an alert:
 
-1. In your project, navigate to **{cloud-gear}** **Operations > Metrics**,
+1. In your project, navigate to **Operations > Metrics**,
 1. Identify the metric you want to create the alert for, and click the
    **ellipsis** **{ellipsis_v}** icon in the top right corner of the metric.
 1. Choose **Alerts**.

doc/operations/metrics/dashboards/index.md

@@ -23,15 +23,14 @@ The metrics as defined below do not support alerts, unlike
 > UI option [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/223204) in GitLab 13.2.
 
 You can configure a custom dashboard by adding a new YAML file into your project's
-`.gitlab/dashboards/` directory. For the dashboard to display on your project's
-**{cloud-gear}** **Operations > Metrics** page, the files must have a `.yml`
+`.gitlab/dashboards/` directory. For the dashboard to display on your project's **Operations > Metrics** page, the files must have a `.yml`
 extension and be present in your project's **default** branch.
 
 To create a new dashboard from the GitLab user interface:
 
 1. Sign in to GitLab as a user with Maintainer or Owner
    [permissions](../../../user/permissions.md#project-members-permissions).
-1. Navigate to your dashboard at **{cloud-gear}** **Operations > Metrics**.
+1. Navigate to your dashboard at **Operations > Metrics**.
 1. In the top-right corner of your dashboard, click the **{file-addition-solid}** **Actions** menu,
    and select **Create new**:
    ![Monitoring Dashboard actions menu with create new item](img/actions_menu_create_new_dashboard_v13_2.png)
@@ -103,7 +102,7 @@ To manage the settings for your metrics dashboard:
 
 1. Sign in as a user with project Maintainer or Admin
    [permissions](../../../user/permissions.md#project-members-permissions).
-1. Navigate to your dashboard at **{cloud-gear}** **Operations > Metrics**.
+1. Navigate to your dashboard at **Operations > Metrics**.
 1. In the top-right corner of your dashboard, click **Metrics Settings**:
 
    ![Monitoring Dashboard actions menu with create new item](img/metrics_settings_button_v13_2.png)

doc/operations/metrics/index.md

@@ -20,7 +20,7 @@ To view the metrics dashboard for an environment that has
 
 1. *If the metrics dashboard is only visible to project members,* sign in to
    GitLab as a member of a project. Learn more about [metrics dashboard visibility](#metrics-dashboard-visibility).
-1. In your project, navigate to **{cloud-gear}** **Operations > Metrics**.
+1. In your project, navigate to **Operations > Metrics**.
 
 GitLab displays the default metrics dashboard for the environment, like the
 following example:
@@ -52,11 +52,11 @@ navigation bar contains:
 ## Populate your metrics dashboard
 
 After [configuring Prometheus for a cluster](../../user/project/integrations/prometheus.md),
-you must also deploy code for the **{cloud-gear}** **Operations > Metrics** page
+you must also deploy code for the **Operations > Metrics** page
 to contain data. Setting up [Auto DevOps](../../topics/autodevops/index.md)
 helps quickly create a deployment:
 
-1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes** page.
+1. Navigate to your project's **Operations > Kubernetes** page.
 1. Ensure that, in addition to Prometheus, you also have Runner and Ingress
    installed.
 1. After installing Ingress, copy its endpoint.
@@ -68,7 +68,7 @@ helps quickly create a deployment:
 1. Navigate to your project's **{rocket}** **CI/CD > Pipelines** page, and run a
    pipeline on any branch.
 1. When the pipeline has run successfully, graphs are available on the
-   **{cloud-gear}** **Operations > Metrics** page.
+   **Operations > Metrics** page.
 
 ![Monitoring Dashboard](img/prometheus_monitoring_dashboard_v13_1.png)
 

doc/operations/product_analytics.md

@@ -52,7 +52,7 @@ user interface:
 
 1. Sign in to GitLab as a user with Reporter or greater
    [permissions](../user/permissions.md).
-1. Navigate to **{cloud-gear}** **Operations > Product Analytics**
+1. Navigate to **Operations > Product Analytics**
 
 The user interface contains:
 

doc/topics/autodevops/index.md

@@ -276,14 +276,14 @@ The following table is an example of how to configure the three different cluste
 
 To add a different cluster for each environment:
 
-1. Navigate to your project's **{cloud-gear}** **Operations > Kubernetes**.
+1. Navigate to your project's **Operations > Kubernetes**.
 1. Create the Kubernetes clusters with their respective environment scope, as
    described from the table above.
 1. After creating the clusters, navigate to each cluster and install
    Ingress. Wait for the Ingress IP address to be assigned.
 1. Make sure you've [configured your DNS](#auto-devops-base-domain) with the
    specified Auto DevOps domains.
-1. Navigate to each cluster's page, through **{cloud-gear}** **Operations > Kubernetes**,
+1. Navigate to each cluster's page, through **Operations > Kubernetes**,
    and add the domain based on its Ingress IP address.
 
 After completing configuration, you can test your setup by creating a merge request

doc/topics/autodevops/quick_start_guide.md

@@ -57,7 +57,7 @@ to deploy this project to.
 ## Create a Kubernetes cluster from within GitLab
 
 1. On your project's landing page, click **Add Kubernetes cluster**
-   (note that this option is also available when you navigate to **{cloud-gear}** **Operations > Kubernetes**).
+   (note that this option is also available when you navigate to **Operations > Kubernetes**).
 
    ![Project landing page](img/guide_project_landing_page_v12_10.png)
 
@@ -194,7 +194,7 @@ to monitor it.
 
 After successfully deploying your application, you can view its website and check
 on its health on the **Environments** page by navigating to
-**{cloud-gear}** **Operations > Environments**. This page displays details about
+**Operations > Environments**. This page displays details about
 the deployed applications, and the right-hand column displays icons that link
 you to common environment tasks:
 

doc/topics/autodevops/stages.md

@@ -650,6 +650,6 @@ To use Auto Monitoring:
 1. After the pipeline finishes successfully, open the
    [monitoring dashboard for a deployed environment](../../ci/environments/index.md#monitoring-environments)
    to view the metrics of your deployed application. To view the metrics of the
-   whole Kubernetes cluster, navigate to **{cloud-gear}** **Operations > Metrics**.
+   whole Kubernetes cluster, navigate to **Operations > Metrics**.
 
 ![Auto Metrics](img/auto_monitoring.png)

doc/user/admin_area/index.md

@@ -59,13 +59,13 @@ The Dashboard is the default view of the Admin Area, and is made up of the follo
 
 ## Overview section
 
-The following topics document the **{overview}** **Overview** section of the Admin Area.
+The following topics document the **Overview** section of the Admin Area.
 
 ### Administering Projects
 
 You can administer all projects in the GitLab instance from the Admin Area's Projects page.
 
-To access the Projects page, go to **Admin Area >** **{overview}** **Overview > Projects**.
+To access the Projects page, go to **Admin Area > Overview > Projects**.
 
 Click the **All**, **Private**, **Internal**, or **Public** tab to list only projects of that
 criteria.
@@ -105,7 +105,7 @@ You can combine the filter options. For example, to list only public projects wi
 
 You can administer all users in the GitLab instance from the Admin Area's Users page.
 
-To access the Users page, go to **Admin Area >** **{overview}** **Overview > Users**.
+To access the Users page, go to **Admin Area > Overview > Users**.
 
 To list users matching a specific criteria, click on one of the following tabs on the **Users** page:
 
@@ -157,7 +157,7 @@ reflected in the statistics.
 
 You can administer all groups in the GitLab instance from the Admin Area's Groups page.
 
-To access the Groups page, go to **Admin Area >** **{overview}** **Overview > Groups**.
+To access the Groups page, go to **Admin Area > Overview > Groups**.
 
 For each group, the page displays their name, description, size, number of projects in the group,
 number of members, and whether the group is private, internal, or public. To edit a group, click
@@ -176,7 +176,7 @@ To [Create a new group](../group/index.md#create-a-new-group) click **New group*
 
 You can administer all jobs in the GitLab instance from the Admin Area's Jobs page.
 
-To access the Jobs page, go to **Admin Area >** **{overview}** **Overview > Jobs**.
+To access the Jobs page, go to **Admin Area > Overview > Jobs**.
 
 All jobs are listed, in descending order of job ID.
 
@@ -201,7 +201,7 @@ For each job, the following details are listed:
 You can administer all Runners in the GitLab instance from the Admin Area's **Runners** page. See
 [GitLab Runner](https://docs.gitlab.com/runner/) for more information on Runner itself.
 
-To access the **Runners** page, go to **Admin Area >** **{overview}** **Overview > Runners**.
+To access the **Runners** page, go to **Admin Area > Overview > Runners**.
 
 The **Runners** page features:
 
@@ -247,7 +247,7 @@ You can also edit, pause, or remove each Runner.
 You can list all Gitaly servers in the GitLab instance from the Admin Area's **Gitaly Servers**
 page. For more details, see [Gitaly](../../administration/gitaly/index.md).
 
-To access the **Gitaly Servers** page, go to **Admin Area >** **{overview}** **Overview > Gitaly Servers**.
+To access the **Gitaly Servers** page, go to **Admin Area > Overview > Gitaly Servers**.
 
 For each Gitaly server, the following details are listed:
 
@@ -261,7 +261,7 @@ For each Gitaly server, the following details are listed:
 
 ## Monitoring section
 
-The following topics document the **{monitor}** **Monitoring** section of the Admin Area.
+The following topics document the **Monitoring** section of the Admin Area.
 
 ### System Info
 

doc/user/clusters/applications.md

@@ -28,9 +28,9 @@ This namespace:
 To see a list of available applications to install. For a:
 
 - [Project-level cluster](../project/clusters/index.md), navigate to your project's
-  **{cloud-gear}** **Operations > Kubernetes**.
+  **Operations > Kubernetes**.
 - [Group-level cluster](../group/clusters/index.md), navigate to your group's
-  **{cloud-gear}** **Kubernetes** page.
+  **Kubernetes** page.
 
 NOTE: **Note:**
 As of GitLab 11.6, Helm will be upgraded to the latest version supported
@@ -343,7 +343,7 @@ To help you tune your WAF rules, you can globally set your WAF to either
 To change your WAF's mode:
 
 1. [Install ModSecurity](../../topics/web_application_firewall/quick_start_guide.md) if you have not already done so.
-1. Navigate to **{cloud-gear}** **Operations > Kubernetes**.
+1. Navigate to **Operations > Kubernetes**.
 1. In **Applications**, scroll to **Ingress**.
 1. Under **Global default**, select your desired mode.
 1. Click **Save changes**.
@@ -535,7 +535,7 @@ To enable log shipping:
 
 1. Ensure your cluster contains at least 3 nodes of instance types larger than
    `f1-micro`, `g1-small`, or `n1-standard-1`.
-1. Navigate to **{cloud-gear}** **Operations > Kubernetes**.
+1. Navigate to **Operations > Kubernetes**.
 1. In **Kubernetes Cluster**, select a cluster.
 1. In the **Applications** section, find **Elastic Stack** and click **Install**.
 
@@ -601,7 +601,7 @@ your data. Fluentd sends logs in syslog format.
 
 To enable Fluentd:
 
-1. Navigate to **{cloud-gear}** **Operations > Kubernetes** and click
+1. Navigate to **Operations > Kubernetes** and click
    **Applications**. You will be prompted to enter a host, port and protocol
    where the WAF logs will be sent to via syslog.
 1. Provide the host domain name or URL in **SIEM Hostname**.

doc/user/group/clusters/index.md

@@ -84,7 +84,7 @@ your cluster, which can cause deployment jobs to fail.
 
 To clear the cache:
 
-1. Navigate to your group’s **{cloud-gear}** **Kubernetes** page,
+1. Navigate to your group’s **Kubernetes** page,
    and select your cluster.
 1. Expand the **Advanced settings** section.
 1. Click **Clear cluster cache**.

doc/user/project/clusters/add_eks_clusters.md

@@ -56,9 +56,9 @@ Generate an access key for the IAM user, and configure GitLab with the credentia
 To create and add a new Kubernetes cluster to your project, group, or instance:
 
 1. Navigate to your:
-   - Project's **{cloud-gear}** **Operations > Kubernetes** page, for a project-level cluster.
-   - Group's **{cloud-gear}** **Kubernetes** page, for a group-level cluster.
-   - **Admin Area >** **{cloud-gear}** **Kubernetes**, for an instance-level cluster.
+   - Project's **Operations > Kubernetes** page, for a project-level cluster.
+   - Group's **Kubernetes** page, for a group-level cluster.
+   - **Admin Area > Kubernetes**, for an instance-level cluster.
 1. Click **Add Kubernetes cluster**.
 1. Under the **Create new cluster** tab, click **Amazon EKS**. You will be provided with an
    `Account ID` and `External ID` to use in the next step.