Add latest changes from gitlab-org/gitlab@master

.gitlab/ci/qa.gitlab-ci.yml

 # Make sure to update all the similar conditions in other CI config files if you modify these conditions
 .if-canonical-gitlab-schedule: &if-canonical-gitlab-schedule
-  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_PIPELINE_SOURCE == "schedule"'
+  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE == "gitlab-org" && $CI_PIPELINE_SOURCE == "schedule"'
 
 # Make sure to update all the similar conditions in other CI config files if you modify these conditions
 .if-canonical-gitlab-merge-request: &if-canonical-gitlab-merge-request
-  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_MERGE_REQUEST_IID'
+  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE == "gitlab-org" && $CI_MERGE_REQUEST_IID'
 
 # Make sure to update all the similar patterns in other CI config files if you modify these patterns
 .code-patterns: &code-patterns

.gitlab/ci/review.gitlab-ci.yml

 # Make sure to update all the similar conditions in other CI config files if you modify these conditions
 .if-canonical-gitlab-schedule: &if-canonical-gitlab-schedule
-  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_PIPELINE_SOURCE == "schedule"'
+  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE == "gitlab-org" && $CI_PIPELINE_SOURCE == "schedule"'
 
 # Make sure to update all the similar conditions in other CI config files if you modify these conditions
 .if-canonical-gitlab-merge-request: &if-canonical-gitlab-merge-request
-  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE =~ /^gitlab-org($|\/)/ && $CI_MERGE_REQUEST_IID'
+  if: '$CI_SERVER_HOST == "gitlab.com" && $CI_PROJECT_NAMESPACE == "gitlab-org" && $CI_MERGE_REQUEST_IID'
 
 # Make sure to update all the similar patterns in other CI config files if you modify these patterns
 .code-qa-patterns: &code-qa-patterns

app/services/clusters/aws/provision_service.rb

@@ -38,8 +38,7 @@ module Clusters
       def credentials
         @credentials ||= Clusters::Aws::FetchCredentialsService.new(
           provision_role,
-          provider: provider,
-          region: provider.region
+          provider: provider
         ).execute
       end
 

changelogs/unreleased/121751-new-eks-cluster-results-in-error-unknown-keyword-region.yml

+---
+title: Remove unused keyword from EKS provision service
+merge_request: 22633
+author:
+type: fixed

doc/administration/auditor_users.md

@@ -9,7 +9,7 @@ resources on the GitLab instance.
 
 Auditor users can have full access to their own resources (projects, groups,
 snippets, etc.), and read-only access to **all** other resources, except the
-Admin area. To put another way, they are just regular users (who can be added
+Admin Area. To put another way, they are just regular users (who can be added
 to projects, create personal snippets, create milestones on their groups, etc.)
 who also happen to have read-only access to all projects on the system that
 they haven't been explicitly [given access][permissions] to.
@@ -28,7 +28,7 @@ To sum up, assuming you have logged-in as an Auditor user:
   have the same access as the [permissions] they were given to. For example, if
   they were added as a Developer, they could then push commits or comment on
   issues.
-- The Auditor cannot view the Admin area, or perform any admin actions.
+- The Auditor cannot view the Admin Area, or perform any admin actions.
 
 For more information about what an Auditor can or can't do, see the
 [Permissions and restrictions of an Auditor user](#permissions-and-restrictions-of-an-auditor-user)
@@ -73,7 +73,7 @@ instance, with the following permissions/restrictions:
 - Can read issues / MRs
 - Can read project snippets
 - Cannot be Admin and Auditor at the same time
-- Cannot access the Admin area
+- Cannot access the Admin Area
 - In a group / project they're not a member of:
   - Cannot access project settings
   - Cannot access group settings

doc/administration/auth/ldap-ee.md

@@ -452,7 +452,7 @@ things to check to debug the situation.
   links by visiting the GitLab group, then **Settings dropdown > LDAP groups**.
 - Check that the user has an LDAP identity:
   1. Sign in to GitLab as an administrator user.
-  1. Navigate to **Admin area > Users**.
+  1. Navigate 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

doc/administration/auth/ldap.md

@@ -52,7 +52,7 @@ If a user is deleted from the LDAP server, they will be blocked in GitLab as
 well. Users will be immediately blocked from logging in. However, there is an
 LDAP check cache time of one hour (see note) which means users that
 are already logged in or are using Git over SSH will still be able to access
-GitLab for up to one hour. Manually block the user in the GitLab Admin area to
+GitLab for up to one hour. Manually block the user in the GitLab Admin Area to
 immediately block all access.
 
 NOTE: **Note**:

doc/administration/geo/replication/troubleshooting.md

@@ -208,9 +208,9 @@ sudo gitlab-rake gitlab:geo:check
     Checking Geo ... Finished
     ```
 
-    - Ensure that you have added the secondary node in the admin area of the primary node.
+    - Ensure that you have added the secondary node in the Admin Area of the primary node.
     - Ensure that you entered the `external_url` or `gitlab_rails['geo_node_name']` when adding the secondary node in the admin are of the primary node.
-    - Prior to GitLab 12.4, edit the secondary node in the admin area of the primary node and ensure that there is a trailing `/` in the `Name` field.
+    - Prior to GitLab 12.4, edit the secondary node in the Admin Area of the primary node and ensure that there is a trailing `/` in the `Name` field.
 
 1. Check returns Exception: PG::UndefinedTable: ERROR:  relation "geo_nodes" does not exist
 

doc/administration/integration/terminal.md

@@ -96,6 +96,6 @@ they will receive a `Connection failed` message.
 in GitLab 8.17.
 
 Terminal sessions use long-lived connections; by default, these may last
-forever. You can configure a maximum session time in the Admin area of your
+forever. You can configure a maximum session time in the Admin Area of your
 GitLab instance if you find this undesirable from a scalability or security
 point of view.

doc/administration/job_artifacts.md

@@ -267,7 +267,7 @@ you can flip the feature flag from a Rails console.
 ## Set the maximum file size of the artifacts
 
 Provided the artifacts are enabled, you can change the maximum file size of the
-artifacts through the [Admin area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
+artifacts through the [Admin Area settings](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size-core-only).
 
 ## Storage statistics
 

doc/administration/monitoring/performance/grafana_configuration.md

@@ -113,14 +113,14 @@ repository for more information on this process.
 
 If you have set up Grafana, you can enable a link to access it easily from the sidebar:
 
-1. Go to the admin area under **Settings > Metrics and profiling**
-   and expand "Metrics - Grafana".
+1. Go to the **Admin Area > Settings > Metrics and profiling**.
+1. Expand **Metrics - Grafana**.
 1. Check the "Enable access to Grafana" checkbox.
 1. If Grafana is enabled through Omnibus GitLab and on the same server,
    leave "Grafana URL" unchanged. In any other case, enter the full URL
    path of the Grafana instance.
 1. Click **Save changes**.
-1. The new link will be available in the admin area under **Monitoring > Metrics Dashboard**.
+1. The new link will be available in the **Admin Area > Monitoring > Metrics Dashboard**.
 
 ## Security Update
 

doc/administration/monitoring/performance/performance_bar.md

@@ -52,8 +52,9 @@ And requests with warnings are indicated in the request selector with a
 ## Enable the Performance Bar via the Admin panel
 
 GitLab Performance Bar is disabled by default. To enable it for a given group,
-navigate to the Admin area in **Settings > Metrics and Profiling > Profiling - Performance bar**
-(`admin/application_settings/metrics_and_profiling`).
+navigate to **Admin Area > Settings > Metrics and profiling**
+(`admin/application_settings/metrics_and_profiling`), and expand the section
+**Profiling - Performance bar**.
 
 The only required setting you need to set is the full path of the group that
 will be allowed to display the Performance Bar.

doc/administration/monitoring/prometheus/gitlab_metrics.md

@@ -6,8 +6,8 @@ installations from source you'll have to configure it yourself.
 
 To enable the GitLab Prometheus metrics:
 
-1. Log into GitLab as an administrator, and go to the Admin area.
-1. Navigate to GitLab's **Settings > Metrics and profiling**.
+1. Log into GitLab as an administrator.
+1. Navigate 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.
 

doc/administration/operations/extra_sidekiq_processes.md

@@ -59,8 +59,8 @@ To start extra Sidekiq processes, you must enable `sidekiq-cluster`:
    sudo gitlab-ctl reconfigure
    ```
 
-Once the extra Sidekiq processes are added, you can visit the "Background Jobs"
-section under the admin area in GitLab (`/admin/background_jobs`).
+Once the extra Sidekiq processes are added, you can visit the
+**Admin Area > Monitoring > Background Jobs** (`/admin/background_jobs`) in GitLab.
 
 ![Extra Sidekiq processes](img/sidekiq-cluster.png)
 

doc/administration/pages/index.md

@@ -257,8 +257,8 @@ When adding a custom domain, users will be required to prove they own it by
 adding a GitLab-controlled verification code to the DNS records for that domain.
 
 If your userbase is private or otherwise trusted, you can disable the
-verification requirement. Navigate to `Admin area ➔ Settings` and uncheck
-**Require users to prove ownership of custom domains** in the Pages section.
+verification requirement. Navigate 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.
 
 ### Let's Encrypt integration
@@ -395,8 +395,8 @@ Omnibus GitLab 11.1.
 
 ## Set maximum pages size
 
-You can configure the maximum size of the unpacked archive per project in the
-Admin area. Under Application settings, edit the **Maximum size of pages (MB)**.
+You can configure the maximum size of the unpacked archive per project in
+**Admin Area > Settings > Preferences > Pages**, in **Maximum size of pages (MB)**.
 The default is 100MB.
 
 ### Override maximum pages size per project or group **(PREMIUM ONLY)**

doc/administration/pages/source.md

@@ -433,8 +433,8 @@ are stored.
 
 ## Set maximum Pages size
 
-The maximum size of the unpacked archive per project can be configured in the
-Admin area under the Application settings in the **Maximum size of pages (MB)**.
+The maximum size of the unpacked archive per project can be configured in
+**Admin Area > Settings > Preferences > Pages**, in **Maximum size of pages (MB)**.
 The default is 100MB.
 
 ## Backup

doc/administration/repository_storage_paths.md

@@ -110,7 +110,7 @@ Once you set the multiple storage paths, you can choose where new projects will
 be stored under **Admin Area > Settings > Repository > Repository storage > Storage
 nodes for new projects**.
 
-![Choose repository storage path in Admin area](img/repository_storages_admin_ui.png)
+![Choose repository storage path in Admin Area](img/repository_storages_admin_ui.png)
 
 Beginning with GitLab 8.13.4, multiple paths can be chosen. New projects will be
 randomly placed on one of the selected paths.

doc/api/settings.md

@@ -180,7 +180,7 @@ are listed in the descriptions of the relevant settings.
 
 | Attribute | Type | Required | Description |
 | --------- | ---- | :------: | ----------- |
-| `admin_notification_email`               | string           | no                                   | Abuse reports will be sent to this address if it is set. Abuse reports are always available in the admin area. |
+| `admin_notification_email`               | string           | no                                   | Abuse reports will be sent to this address if it is set. Abuse reports are always available in the Admin Area. |
 | `after_sign_out_path`                    | string           | no                                   | Where to redirect users after logout. |
 | `after_sign_up_text`                     | string           | no                                   | Text shown to the user after signing up |
 | `akismet_api_key`                        | string           | required by: `akismet_enabled`       | API key for Akismet spam protection. |

doc/api/system_hooks.md

@@ -3,7 +3,7 @@
 All methods require administrator authorization.
 
 The URL endpoint of the system hooks can also be configured using the UI in
-the admin area under **Hooks** (`/admin/hooks`).
+the **Admin Area > System Hooks** (`/admin/hooks`).
 
 Read more about [system hooks](../system_hooks/system_hooks.md).
 

doc/ci/runners/README.md

@@ -62,7 +62,7 @@ You can only register a shared Runner if you are an admin of the GitLab instance
 
 1. Grab the shared-Runner token on the `admin/runners` page
 
-   ![Shared Runners admin area](img/shared_runners_admin.png)
+   ![Shared Runners Admin Area](img/shared_runners_admin.png)
 
 1. [Register the Runner][register]
 
@@ -100,7 +100,7 @@ If you are an admin on your GitLab instance, you can turn any shared Runner into
 a specific one, but not the other way around. Keep in mind that this is a one
 way transition.
 
-1. Go to the Runners in the admin area **Overview > Runners** (`/admin/runners`)
+1. Go to the Runners in the **Admin Area > Overview > Runners** (`/admin/runners`)
    and find your Runner
 1. Enable any projects under **Restrict projects for this Runner** to be used
    with the Runner
@@ -402,7 +402,7 @@ different places.
 To view the IP address of a shared Runner you must have admin access to
 the GitLab instance. To determine this:
 
-1. Visit **Admin area ➔ Overview ➔ Runners**
+1. Visit **Admin Area ➔ Overview ➔ Runners**
 1. Look for the Runner in the table and you should see a column for "IP Address"
 
 ![shared Runner IP address](img/shared_runner_ip_address.png)

doc/development/documentation/site_architecture/global_nav.md

@@ -86,7 +86,7 @@ The available sections are described on the table below:
 | Section       | Description                                |
 | ------------- | ------------------------------------------ |
 | User          | Documentation for the GitLab's user UI.    |
-| Administrator | Documentation for the GitLab's admin area. |
+| Administrator | Documentation for the GitLab's Admin Area. |
 | Contributor   | Documentation for developing GitLab.       |
 
 The majority of the links available on the nav were added according to the UI.

doc/development/event_tracking/index.md

@@ -53,7 +53,7 @@ Tracking can be enabled at:
 
 We utilize Snowplow for the majority of our tracking strategy, and it can be enabled by navigating to:
 
-- **Admin area > Settings > Integrations** in the UI.
+- **Admin Area > Settings > Integrations** in the UI.
 - `admin/application_settings/integrations` in your browser.
 
 The following configuration is required:

doc/integration/elasticsearch.md

@@ -40,7 +40,7 @@ NOTE: **Note:**
 **For a single node Elasticsearch cluster the functional cluster health status will be yellow** (will never be green) because the primary shard is allocated but replicas can not be as there is no other node to which Elasticsearch can assign a replica.
 
 Once the data is added to the database or repository and [Elasticsearch is
-enabled in the admin area](#enabling-elasticsearch) the search index will be
+enabled in the Admin Area](#enabling-elasticsearch) the search index will be
 updated automatically.
 
 ## Elasticsearch repository indexer
@@ -201,7 +201,7 @@ To backfill existing data, you can use one of the methods below to index it in b
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/15390) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.3.
 
-To index via the admin area:
+To index via the Admin Area:
 
 1. [Configure your Elasticsearch host and port](#enabling-elasticsearch).
 1. Create empty indexes using one of the following commands:

doc/integration/oauth_provider.md

@@ -26,7 +26,7 @@ The 'GitLab Importer' feature is also using the OAuth protocol to give access
 to repositories without sharing user credentials to your GitLab.com account.
 
 GitLab supports two ways of adding a new OAuth2 application to an instance. You
-can either add an application as a regular user or add it in the admin area.
+can either add an application as a regular user or add it in the Admin Area.
 What this means is that GitLab can actually have instance-wide and a user-wide
 applications. There is no difference between them except for the different
 permission levels they are set (user/admin). The default callback URL is
@@ -51,14 +51,14 @@ connects to GitLab.
 
 ![OAuth application ID and secret](img/oauth_provider_application_id_secret.png)
 
-## OAuth applications in the admin area
+## OAuth applications in the Admin Area
 
 To create an application that does not belong to a certain user, you can create
-it from the admin area.
+it from the Admin Area.
 
 ![OAuth admin_applications](img/oauth_provider_admin_application.png)
 
-You're also able to mark an application as _trusted_ when creating it through the admin area. By doing that,
+You're also able to mark an application as _trusted_ when creating it through the Admin Area. By doing that,
 the user authorization step is automatically skipped for this application.
 
 ## Authorized applications

doc/push_rules/push_rules.md

@@ -52,7 +52,7 @@ will get rejected.
 ### Custom Push Rules **(CORE ONLY)**
 
 It's possible to create custom push rules rather than the push rules available in
-**Admin area > Push Rules** by using more advanced server-side Git hooks.
+**Admin Area > Push Rules** by using more advanced server-side Git hooks.
 
 See [custom server-side Git hooks](../administration/custom_hooks.md) for more information.
 
@@ -60,7 +60,7 @@ See [custom server-side Git hooks](../administration/custom_hooks.md) for more i
 
 NOTE: **Note:**
 GitLab administrators can set push rules globally under
-**Admin area > Push Rules** that all new projects will inherit. You can later
+**Admin Area > Push Rules** that all new projects will inherit. You can later
 override them in a project's settings.
 
 1. Navigate to your project's **Settings > Repository** and expand **Push Rules**

doc/security/password_length_limits.md

@@ -49,7 +49,7 @@ From GitLab 12.6, the minimum password length set in this configuration file wil
 The user password length is set to a minimum of 8 characters by default.
 To change that using GitLab UI:
 
-In the Admin area under **Settings** (`/admin/application_settings`), go to section **Sign-up Restrictions**.
+In **Admin Area > Settings** (`/admin/application_settings`), go to the section **Sign-up restrictions**.
 
 [Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)
 

doc/security/ssh_keys_restrictions.md

@@ -17,8 +17,8 @@ algorithms.
 GitLab allows you to restrict the allowed SSH key technology as well as specify
 the minimum key length for each technology.
 
-In the Admin area under **Settings** (`/admin/application_settings`), look for
-the "Visibility and Access Controls" area:
+In **Admin Area > Settings** (`/admin/application_settings`), expand the
+**Visibility and access controls** section:
 
 ![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
 

doc/security/two_factor_authentication.md

@@ -25,7 +25,7 @@ won't be able to leave the 2FA configuration area at `/profile/two_factor_auth`.
 
 To enable 2FA for all users:
 
-1. Navigate to **Admin area > Settings > General** (`/admin/application_settings`).
+1. Navigate to **Admin Area > Settings > General** (`/admin/application_settings`).
 1. Expand the **Sign-in restrictions** section, where you can configure both.
 
 If you want 2FA enforcement to take effect on next login, change the grace

doc/security/user_email_confirmation.md

@@ -8,7 +8,7 @@ GitLab can be configured to require confirmation of a user's email address when
 the user signs up. When this setting is enabled, the user is unable to sign in until
 they confirm their email address.
 
-In the Admin area under **Settings** (`/admin/application_settings`), go to section
+In **Admin Area > Settings** (`/admin/application_settings`), go to the section
 **Sign-up Restrictions** and look for the **Send confirmation email on sign-up** option.
 
 <!-- ## Troubleshooting

doc/security/webhooks.md

@@ -40,8 +40,7 @@ to `127.0.0.1`, `::1` and `0.0.0.0`, as well as IPv4 `10.0.0.0/8`, `172.16.0.0/1
 
 This behavior can be overridden by enabling the option *"Allow requests to the
 local network from web hooks and services"* in the *"Outbound requests"* section
-inside the Admin area under **Settings**
-(`/admin/application_settings/network`):
+inside the **Admin Area > Settings** (`/admin/application_settings/network`):
 
 ![Outbound requests admin settings](img/outbound_requests_section_v12_2.png)
 

doc/ssh/README.md

@@ -376,7 +376,7 @@ Global Shared Keys can provide greater security compared to Per-Project Deploy
 Keys since an administrator of the target integrated system is the only one
 who needs to know and configure the private key.
 
-GitLab administrators set up Global Deploy keys in the Admin area under the
+GitLab administrators set up Global Deploy keys in the Admin Area under the
 section **Deploy Keys**. Ensure keys have a meaningful title as that will be
 the primary way for project maintainers and owners to identify the correct Global
 Deploy key to add. For instance, if the key gives access to a SaaS CI instance,

doc/tools/email.md

@@ -5,7 +5,7 @@ type: howto, reference
 # Email from GitLab **(STARTER ONLY)**
 
 GitLab provides a simple tool to administrators for emailing all users, or users of
-a chosen group or project, right from the admin area. Users will receive the email
+a chosen group or project, right from the Admin Area. Users will receive the email
 at their primary email address.
 
 ## Use-cases
@@ -16,8 +16,8 @@ at their primary email address.
 
 ## Sending emails to users from within GitLab
 
-1. Go to the admin area using the wrench icon in the top right corner and
-   navigate to **Overview > Users > Send email to users**.
+1. Navigate to the **Admin Area > Overview > Users** and press the
+   **Send email to users** button.
 
    ![admin users](email1.png)
 

doc/topics/autodevops/index.md

@@ -184,7 +184,7 @@ The Auto DevOps base domain is required if you want to make use of
 places:
 
 - either under the cluster's settings, whether for [projects](../../user/project/clusters/index.md#base-domain) or [groups](../../user/group/clusters/index.md#base-domain)
-- or in instance-wide settings in the **admin area > Settings** under the "Continuous Integration and Delivery" section
+- or in instance-wide settings in the **Admin Area > Settings** under the "Continuous Integration and Delivery" section
 - or at the project level as a variable: `KUBE_INGRESS_BASE_DOMAIN`
 - or at the group level as a variable: `KUBE_INGRESS_BASE_DOMAIN`.
 
@@ -263,7 +263,7 @@ the subgroup or project.
 Even when disabled at the instance level, group owners and project maintainers can still enable
 Auto DevOps at the group and project level, respectively.
 
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
+1. Go to **Admin Area > Settings > Continuous Integration and Deployment**.
 1. Toggle the checkbox labeled **Default to Auto DevOps pipeline for all projects**.
 1. If enabling, optionally set up the Auto DevOps [base domain](#auto-devops-base-domain) which will be used for Auto Deploy and Auto Review Apps.
 1. Click **Save changes** for the changes to take effect.

doc/user/admin_area/custom_project_templates.md

@@ -28,7 +28,7 @@ see [Custom group-level project templates](../group/custom_project_templates.md)
 GitLab administrators can configure a GitLab group that serves as template
 source for an entire GitLab instance by:
 
-1. Navigating to **Admin area > Settings > Templates**.
+1. Navigating to **Admin Area > Settings > Templates**.
 1. Expanding **Custom project templates**.
 1. Selecting a group to use.
 1. Pressing **Save changes**.

doc/user/admin_area/diff_limits.md

@@ -24,7 +24,7 @@ CAUTION: **Caution:**
 This setting is experimental. An increased maximum will increase resource
 consumption of your instance. Keep this in mind when adjusting the maximum.
 
-1. Go to **Admin area > Settings > General**.
+1. Go to **Admin Area > Settings > General**.
 1. Expand **Diff limits**.
 1. Enter a value for **Maximum diff patch size**, measured in bytes.
 1. Click on **Save changes**.

doc/user/admin_area/geo_nodes.md

@@ -2,12 +2,12 @@
 type: howto
 ---
 
-# Geo nodes admin area **(PREMIUM ONLY)**
+# Geo nodes Admin Area **(PREMIUM ONLY)**
 
 You can configure various settings for GitLab Geo nodes. For more information, see
 [Geo documentation](../../administration/geo/replication/index.md).
 
-On the primary node, go to **Admin area > Geo**. On secondary nodes, go to **Admin area > Geo > Nodes**.
+On the primary node, go to **Admin Area > Geo**. On secondary nodes, go to **Admin Area > Geo > Nodes**.
 
 ## Common settings
 
@@ -59,7 +59,7 @@ The **primary** node's Internal URL is used by **secondary** nodes to contact it
 which is used by users. Internal URL does not need to be a private address.
 
 Internal URL defaults to External URL, but you can customize it under
-**Admin area > Geo Nodes**.
+**Admin Area > Geo > Nodes**.
 
 CAUTION: **Warning:**
 We recommend using an HTTPS connection while configuring the Geo nodes. To avoid

doc/user/admin_area/license.md

@@ -24,17 +24,17 @@ will be locked.
 
 The very first time you visit your GitLab EE installation signed in as an admin,
 you should see a note urging you to upload a license with a link that takes you
-straight to the License admin area.
+straight to **Admin Area > License**.
 
 Otherwise, you can:
 
 1. Navigate manually to the **Admin Area** by clicking the wrench icon in the menu bar.
 
-   ![Admin area icon](img/admin_wrench.png)
+   ![Admin Area icon](img/admin_wrench.png)
 
 1. And then going to the **License** tab and click on **Upload New License**.
 
-   ![License admin area](img/license_admin_area.png)
+   ![License Admin Area](img/license_admin_area.png)
 
 1. If you've received a `.gitlab-license` file, you should have already downloaded
    it in your local machine. You can then upload it directly by choosing the
@@ -69,7 +69,7 @@ gitlab_rails['license_file'] = "/path/to/license/file"
 
 CAUTION: **Caution:**
 These methods will only add a license at the time of installation. Use the
-admin area in the web ui to renew or upgrade licenses.
+Admin Area in the web ui to renew or upgrade licenses.
 
 ---
 

doc/user/admin_area/monitoring/health_check.md

@@ -141,7 +141,7 @@ This check is being exempt from Rack Attack.
 > Access token has been deprecated in GitLab 9.4 in favor of [IP whitelist](#ip-whitelist).
 
 An access token needs to be provided while accessing the probe endpoints. The current
-accepted token can be found under the **Admin area ➔ Monitoring ➔ Health check**
+accepted token can be found under the **Admin Area ➔ Monitoring ➔ Health check**
 (`admin/health_check`) page of your GitLab instance.
 
 ![access token](img/health_check_token.png)

doc/user/admin_area/settings/continuous_integration.md

@@ -5,16 +5,16 @@ type: reference
 # Continuous Integration and Deployment Admin settings **(CORE ONLY)**
 
 In this area, you will find settings for Auto DevOps, Runners and job artifacts.
-You can find it in the admin area, under **Settings > Continuous Integration and Deployment**.
+You can find it in the **Admin Area > Settings > CI/CD**.
 
-![Admin area settings button](../img/admin_area_settings_button.png)
+![Admin Area settings button](../img/admin_area_settings_button.png)
 
 ## Auto DevOps **(CORE ONLY)**
 
 To enable (or disable) [Auto DevOps](../../../topics/autodevops/index.md)
 for all projects:
 
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**
+1. Go to **Admin Area > Settings > CI/CD**
 1. Check (or uncheck to disable) the box that says "Default to Auto DevOps pipeline for all projects"
 1. Optionally, set up the [Auto DevOps base domain](../../../topics/autodevops/index.md#auto-devops-base-domain)
    which is going to be used for Auto Deploy and Auto Review Apps.
@@ -43,7 +43,7 @@ To change it at the:
 
 - Instance level:
 
-   1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
+   1. Go to **Admin Area > Settings > CI/CD**.
    1. Change the value of maximum artifacts size (in MB).
    1. Hit **Save changes** for the changes to take effect.
 
@@ -65,12 +65,12 @@ The setting at all levels is only available to GitLab administrators.
 ## Default artifacts expiration **(CORE ONLY)**
 
 The default expiration time of the [job artifacts](../../../administration/job_artifacts.md)
-can be set in the Admin area of your GitLab instance. The syntax of duration is
+can be set in the Admin Area of your GitLab instance. The syntax of duration is
 described in [`artifacts:expire_in`](../../../ci/yaml/README.md#artifactsexpire_in)
 and the default value is `30 days`. On GitLab.com they
 [never expire](../../gitlab_com/index.md#gitlab-cicd).
 
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
+1. Go to **Admin Area > Settings > CI/CD**.
 1. Change the value of default expiration time.
 1. Hit **Save changes** for the changes to take effect.
 
@@ -99,17 +99,17 @@ On GitLab.com, the quota is calculated based on your
 
 To change the pipelines minutes quota:
 
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**
+1. Go to **Admin Area > Settings > CI/CD**
 1. Set the pipeline minutes quota limit.
 1. Hit **Save changes** for the changes to take effect
 
 ---
 
-While the setting in the Admin area has a global effect, as an admin you can
+While the setting in the Admin Area has a global effect, as an admin you can
 also change each group's pipeline minutes quota to override the global value.
 
-1. Navigate to the **Groups** admin area and hit the **Edit** button for the
-   group you wish to change the pipeline minutes quota.
+1. Navigate to the **Admin Area > Overview > Groups** and hit the **Edit**
+   button for the group you wish to change the pipeline minutes quota.
 1. Set the pipeline minutes quota to the desired value
 1. Hit **Save changes** for the changes to take effect.
 
@@ -132,8 +132,9 @@ but persisting the traces and artifacts for auditing purposes.
 
 To set the duration for which the jobs will be considered as old and expired:
 
-1. Go to **Admin area > Settings > CI/CD > Continuous Integration and Deployment**.
-1. Change the value of "Archive jobs".
+1. Go to **Admin Area > Settings > CI/CD**.
+1. Expand the **Continuous Integration and Deployment** section.
+1. Set the value of **Archive jobs**.
 1. Hit **Save changes** for the changes to take effect.
 
 Once that time passes, the jobs will be archived and no longer able to be
@@ -145,9 +146,9 @@ for example: <code>15 days</code>, <code>1 month</code>, <code>2 years</code>.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/18073) in GitLab 12.5.
 
 The default CI configuration file path for new projects can be set in the Admin
-area of your GitLab instance (`.gitlab-ci.yml` if not set):
+Area of your GitLab instance (`.gitlab-ci.yml` if not set):
 
-1. Go to **Admin area > Settings > Continuous Integration and Deployment**.
+1. Go to **Admin Area > Settings > CI/CD**.
 1. Input the new path in the **Default CI configuration path** field.
 1. Hit **Save changes** for the changes to take effect.
 
@@ -183,7 +184,7 @@ sourced from:
 
 To set required pipeline configuration:
 
-1. Go to **Admin area > Settings > CI/CD**.
+1. Go to **Admin Area > Settings > CI/CD**.
 1. Expand the **Required pipeline configuration** section.
 1. Select the required configuration from the provided dropdown.
 1. Click **Save changes**.

doc/user/admin_area/settings/external_authorization.md

@@ -40,7 +40,7 @@ Read more about logs GitLab keeps in the [omnibus documentation][omnibus-log-doc
 ## Configuration
 
 The external authorization service can be enabled by an admin on the GitLab's
-admin area under the settings page:
+**Admin Area > Settings > General** page:
 
 ![Enable external authorization service](img/external_authorization_service_settings.png)
 

doc/user/admin_area/settings/help_page.md

@@ -13,7 +13,7 @@ to go for help. You can customize and display this information on the GitLab ser
 You can add a help message, which will be shown on the GitLab `/help` page (e.g.,
 <https://gitlab.com/help>) in a new section at the top of the `/help` page:
 
-1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
+1. Navigate to **Admin Area > Settings > Preferences**, then expand **Help page**.
 1. Under **Help page text**, fill in the information you wish to display on `/help`.
 
    ![help page help message](img/help_page_help_page_text_v12_3.png)
@@ -27,7 +27,7 @@ You can add a help message, which will be shown on the GitLab `/help` page (e.g.
 You can add a help message, which will be shown on the GitLab login page in a new section
 titled `Need Help?`, located below the login page message:
 
-1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
+1. Navigate to **Admin Area > Settings > Preferences**, then expand **Help page**.
 1. Under **Help text**, fill in the information you wish to display on the login page.
 
    ![help message on login page](img/help_page_help_text_v12_3.png)