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.