Commit 966ca88b authored by Suzanne Selhorn's avatar Suzanne Selhorn

Changed navigate to go

parent fb075938
......@@ -20,7 +20,7 @@ The steps below cover:
## Configuring Google LDAP client
1. Navigate to <https://admin.google.com/Dashboard> and sign in as a Google Workspace domain administrator.
1. Go to <https://admin.google.com/Dashboard> and sign in as a Google Workspace domain administrator.
1. Go to **Apps > LDAP > Add Client**.
......
......@@ -705,8 +705,8 @@ When enabled, the following applies:
To enable it you need to:
1. [Enable LDAP](#configuration)
1. Navigate to **Admin Area > Settings -> Visibility and access controls**.
1. Make sure the "Lock memberships to LDAP synchronization" checkbox is enabled.
1. Go to **Admin Area > Settings > Visibility and access controls**.
1. Make sure the **Lock memberships to LDAP synchronization** checkbox is selected.
### Adjusting LDAP group sync schedule **(PREMIUM SELF)**
......
......@@ -330,10 +330,10 @@ things to check to debug the situation.
group](index.md#adding-group-links).
- Check that the user has an LDAP identity:
1. Sign in to GitLab as an administrator user.
1. Navigate to **Admin area -> Users**.
1. Go to **Admin area > Users**.
1. Search for the user
1. Open the user, by clicking on their name. Do not click 'Edit'.
1. Navigate to the **Identities** tab. There should be an LDAP identity with
1. Open the user by clicking their name. Do not click **Edit**.
1. Select the **Identities** tab. There should be an LDAP identity with
an LDAP DN as the 'Identifier'. If not, this user hasn't signed in with
LDAP yet and must do so first.
- You've waited an hour or [the configured
......
......@@ -58,14 +58,14 @@ Feature.enable('geo_repository_verification')
## Repository verification
Navigate to the **Admin Area > Geo** dashboard on the **primary** node and expand
Go to the **Admin Area > Geo** dashboard on the **primary** node and expand
the **Verification information** tab for that node to view automatic checksumming
status for repositories and wikis. Successes are shown in green, pending work
in gray, and failures in red.
![Verification status](img/verification-status-primary.png)
Navigate to the **Admin Area > Geo** dashboard on the **secondary** node and expand
Go to the **Admin Area > Geo** dashboard on the **secondary** node and expand
the **Verification information** tab for that node to view automatic verification
status for repositories and wikis. As with checksumming, successes are shown in
green, pending work in gray, and failures in red.
......@@ -92,7 +92,7 @@ data. The default and recommended re-verification interval is 7 days, though
an interval as short as 1 day can be set. Shorter intervals reduce risk but
increase load and vice versa.
Navigate to the **Admin Area > Geo** dashboard on the **primary** node, and
Go to the **Admin Area > Geo** dashboard on the **primary** node, and
click the **Edit** button for the **primary** node to customize the minimum
re-verification interval:
......@@ -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 > Projects** dashboard on the **primary** node, find the
1. Go 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)
......@@ -149,7 +149,7 @@ If the **primary** and **secondary** nodes have a checksum verification mismatch
1. On the project administration page get the **Gitaly storage name**, and **Gitaly relative path**:
![Project administration page](img/checksum-differences-admin-project-page.png)
1. Navigate to the project's repository directory on both **primary** and **secondary** nodes
1. Go to the project's repository directory on both **primary** and **secondary** nodes
(the path is usually `/var/opt/gitlab/git-data/repositories`). Note that if `git_data_dirs`
is customized, check the directory layout on your server to be sure.
......
......@@ -110,7 +110,7 @@ The maintenance window won't end until Geo replication and verification is
completely finished. To keep the window as short as possible, you should
ensure these processes are close to 100% as possible during active use.
Navigate to the **Admin Area > Geo** dashboard on the **secondary** node to
Go to the **Admin Area > Geo** dashboard on the **secondary** node to
review status. Replicated objects (shown in green) should be close to 100%,
and there should be no failures (shown in red). If a large proportion of
objects aren't yet replicated (shown in gray), consider giving the node more
......
......@@ -252,7 +252,7 @@ on the **secondary** node.
Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
method to be enabled. This is enabled by default, but if converting an existing node to Geo it should be checked:
1. Navigate to **Admin Area > Settings** (`/admin/application_settings/general`) on the **primary** node.
1. Go to **Admin Area > Settings** (`/admin/application_settings/general`) on the **primary** node.
1. Expand "Visibility and access controls".
1. Ensure "Enabled Git access protocols" is set to either "Both SSH and HTTP(S)" or "Only HTTP(S)".
......
......@@ -51,8 +51,8 @@ If you haven't yet set up a Geo _primary_ node and _secondary_ node, see the
In a Route53 Hosted Zone, traffic policies can be used to set up a variety of
routing configurations.
1. Navigate to the
[Route53 dashboard](https://console.aws.amazon.com/route53/home) and click
1. Go to the
[Route53 dashboard](https://console.aws.amazon.com/route53/home) and select
**Traffic policies**.
![Traffic policies](img/single_git_traffic_policies.png)
......
......@@ -9,7 +9,7 @@ type: howto
**Secondary** nodes can be removed from the Geo cluster using the Geo administration page of the **primary** node. To remove a **secondary** node:
1. Navigate to **Admin Area > Geo** (`/admin/geo/nodes`).
1. Go to **Admin Area > Geo** (`/admin/geo/nodes`).
1. Click the **Remove** button for the **secondary** node you want to remove.
1. Confirm by clicking **Remove** when the prompt appears.
......
......@@ -56,7 +56,7 @@ You need to enable Kroki integration from Settings under Admin Area.
To do that, log in with an administrator account and follow these steps:
1. Select the Admin Area (**{admin}**) icon.
1. Navigate to **Settings > General**.
1. Go to **Settings > General**.
1. Expand the **Kroki** section.
1. Select **Enable Kroki** checkbox.
1. Enter the **Kroki URL**.
......
......@@ -32,7 +32,7 @@ metrics exposed by the [GitLab exporter](../prometheus/gitlab_metrics.md#metrics
## Creating the self monitoring project
1. Navigate to **Admin Area > Settings > Metrics and profiling**, and expand the **Self monitoring** section.
1. Go to **Admin Area > Settings > Metrics and profiling** and expand the **Self monitoring** section.
1. Toggle the **Create Project** button on.
1. Once your GitLab instance creates the project, GitLab displays a link to the project in the text above the **Create Project** toggle. You can also find it under **Projects > Your projects**.
......@@ -42,7 +42,7 @@ WARNING:
Deleting the self monitoring project removes any changes made to the project. If
you create the project again, it's created in its default state.
1. Navigate to **Admin Area > Settings > Metrics and profiling**, and expand the **Self monitoring** section.
1. Go to **Admin Area > Settings > Metrics and profiling** and expand the **Self monitoring** section.
1. Toggle the **Create Project** button off.
1. In the confirmation dialog that opens, click **Delete project**.
It can take a few seconds for it to be deleted.
......
......@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
GitLab Performance Monitoring is disabled by default. To enable it and change any of its
settings:
1. Navigate to **Admin Area > Settings > Metrics and profiling**
1. Go to **Admin Area > Settings > Metrics and profiling**
(`/admin/application_settings/metrics_and_profiling`).
1. Add the necessary configuration changes.
1. Restart all GitLab for the changes to take effect:
......
......@@ -62,7 +62,7 @@ repository.
After setting up Grafana, you can enable a link to access it easily from the
GitLab sidebar:
1. Navigate to the **Admin Area > Settings > Metrics and profiling**.
1. Go to the **Admin Area > Settings > Metrics and profiling**.
1. Expand **Metrics - Grafana**.
1. Check the **Enable access to Grafana** checkbox.
1. Configure the **Grafana URL**:
......
......@@ -81,7 +81,7 @@ The GitLab Performance Bar is disabled by default. To enable it for a given grou
1. Sign in as a user with Administrator [permissions](../../../user/permissions.md).
1. In the menu bar, click **Admin Area**.
1. Navigate to **Settings > Metrics and profiling**
1. Go to **Settings > Metrics and profiling**
(`admin/application_settings/metrics_and_profiling`), and expand the section
**Profiling - Performance bar**.
1. Click **Enable access to the Performance Bar**.
......
......@@ -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 **Monitoring > Requests Profiles**.
1. Go 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
......
......@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
To enable the GitLab Prometheus metrics:
1. Log into GitLab as a user with [administrator permissions](../../../user/permissions.md).
1. Navigate to **Admin Area > Settings > Metrics and profiling**.
1. Go to **Admin Area > Settings > Metrics and profiling**.
1. Find the **Metrics - Prometheus** section, and click **Enable Prometheus Metrics**.
1. [Restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart) for the changes to take effect.
......
......@@ -351,7 +351,7 @@ When adding a custom domain, users are required to prove they own it by
adding a GitLab-controlled verification code to the DNS records for that domain.
If your user base is private or otherwise trusted, you can disable the
verification requirement. Navigate to **Admin Area > Settings > Preferences** and
verification requirement. Go to **Admin Area > Settings > Preferences** and
uncheck **Require users to prove ownership of custom domains** in the **Pages** section.
This setting is enabled by default.
......@@ -366,7 +366,7 @@ sites served under a custom domain.
To enable it, you must:
1. Choose an email address on which you want to receive notifications about expiring domains.
1. Navigate to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
1. Go to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
1. Enter the email address for receiving notifications and accept Let's Encrypt's Terms of Service as shown below.
1. Click **Save changes**.
......@@ -420,7 +420,7 @@ The scope to use for authentication must match the GitLab Pages OAuth applicatio
pre-existing applications must modify the GitLab Pages OAuth application. Follow these steps to do
this:
1. Navigate to your instance's **Admin Area > Settings > Applications** and expand **GitLab Pages**
1. Go to your instance's **Admin Area > Settings > Applications** and expand **GitLab Pages**
settings.
1. Clear the `api` scope's checkbox and select the desired scope's checkbox (for example,
`read_api`).
......@@ -438,7 +438,7 @@ This can be useful to preserve information published with Pages websites to the
of your instance only.
To do that:
1. Navigate to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
1. Go to your instance's **Admin Area > Settings > Preferences** and expand **Pages** settings.
1. Check the **Disable public access to Pages sites** checkbox.
1. Click **Save changes**.
......@@ -624,13 +624,13 @@ The default is 100MB.
To override the global maximum pages size for a specific project:
1. Navigate to your project's **Settings > Pages** page.
1. Go to your project's **Settings > Pages** page.
1. Edit the **Maximum size of pages**.
1. Click **Save changes**.
To override the global maximum pages size for a specific group:
1. Navigate to your group's **Settings > General** page and expand **Pages**.
1. Go to your group's **Settings > General** page and expand **Pages**.
1. Edit the **Maximum size of pages**.
1. Click **Save changes**.
......
......@@ -51,7 +51,7 @@ repository directory might not exactly match the instructions below. In that cas
Follow the steps below to set up a server-side hook for a repository:
1. Navigate to **Admin area > Projects** and click on the project you want to add a server hook to.
1. Go to **Admin area > Projects** and select the project you want to add a server hook to.
1. Locate the **Gitaly relative path** on the page that appears. This is where the server hook
must be implemented. For information on interpreting the relative path, see
[Translate hashed storage paths](repository_storage_types.md#translate-hashed-storage-paths).
......
......@@ -16,7 +16,7 @@ from an external storage, such as a Content Delivery Network (CDN).
To configure external storage for static objects:
1. Navigate to **Admin Area > Settings > Repository**.
1. Go to **Admin Area > Settings > Repository**.
1. Expand the **Repository static objects** section.
1. Enter the base URL and an arbitrary token. When you [set up external storage](#set-up-external-storage),
use a script that sets these values as `ORIGIN_HOSTNAME` and `STORAGE_TOKEN`.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment