Add latest changes from gitlab-org/gitlab@master

doc/administration/auth/oidc.md

@@ -42,6 +42,7 @@ The OpenID Connect will provide you with a client details and secret for you to
          'discovery' => true,
          'client_auth_method' => 'query',
          'uid_field' => '<uid_field>',
+         'send_scope_to_token_endpoint' => 'false',
          'client_options' => {
            'identifier' => '<your_oidc_client_id>',
            'secret' => '<your_oidc_client_secret>',
@@ -65,6 +66,7 @@ The OpenID Connect will provide you with a client details and secret for you to
            discovery: true,
            client_auth_method: 'query',
            uid_field: '<uid_field>',
+           send_scope_to_token_endpoint: false,
            client_options: {
              identifier: '<your_oidc_client_id>',
              secret: '<your_oidc_client_secret>',
@@ -92,6 +94,8 @@ The OpenID Connect will provide you with a client details and secret for you to
      - If not specified, defaults to `basic`.
    - `<uid_field>` (optional) is the field name from the `user_info` details that will be used as `uid` value. For example, `preferred_username`.
      If this value is not provided or the field with the configured value is missing from the `user_info` details, the `uid` will use the `sub` field.
+   - `send_scope_to_token_endpoint` is `true` by default. In other words, the `scope` parameter is normally included in requests to the token endpoint.
+     However, if your OpenID Connect provider does not accept the `scope` parameter in such requests, set this to `false`.
    - `client_options` are the OpenID Connect client-specific options. Specifically:
      - `identifier` is the client identifier as configured in the OpenID Connect service provider.
      - `secret` is the client secret as configured in the OpenID Connect service provider.

doc/api/services.md

@@ -1145,7 +1145,7 @@ Parameters:
 | `merge_requests_events` | boolean | false | Enable notifications for merge request events |
 | `tag_push_events` | boolean | false | Enable notifications for tag push events |
 | `note_events` | boolean | false | Enable notifications for note events |
-| `confidental_note_events` | boolean | false | Enable notifications for confidential note events |
+| `confidential_note_events` | boolean | false | Enable notifications for confidential note events |
 | `pipeline_events` | boolean | false | Enable notifications for pipeline events |
 | `wiki_page_events` | boolean | false | Enable notifications for wiki page events |

doc/integration/omniauth.md

@@ -51,7 +51,7 @@ that are in common for all providers that we need to consider.
   be created manually or they will not be able to sign in via OmniAuth.
 - `auto_link_ldap_user` can be used if you have [LDAP / ActiveDirectory](ldap.md)
   integration enabled. It defaults to false. When enabled, users automatically
-  created through OmniAuth will be linked to their LDAP entry as well.
+  created through an OmniAuth provider will have their LDAP identity created in GitLab as well.
 - `block_auto_created_users` defaults to `true`. If `true` auto created users will
   be blocked by default and will have to be unblocked by an administrator before
   they are able to sign in.

doc/user/markdown.md

@@ -390,7 +390,7 @@ the [asciidoctor user manual](https://asciidoctor.org/docs/user-manual/#activati
 ### Special GitLab references
 GFM recognizes special GitLab related references. For example, you can easily reference
-an issue, a commit, a team member or even the whole team within a project. GFM will turn
+an issue, a commit, a team member, or even the whole team within a project. GFM will turn
 that reference into a link so you can navigate between them easily.
 Additionally, GFM recognizes certain cross-project references, and also has a shorthand

doc/user/profile/account/two_factor_authentication.md

@@ -160,6 +160,7 @@ have lost your code generation device) you can:
 - [Use a saved recovery code](#use-a-saved-recovery-code).
 - [Generate new recovery codes using SSH](#generate-new-recovery-codes-using-ssh).
+- [Regenerate 2FA recovery codes](#regenerate-2fa-recovery-codes).
 - [Ask a GitLab administrator to disable two-factor authentication on your account](#ask-a-gitlab-administrator-to-disable-two-factor-authentication-on-your-account).
 ### Use a saved recovery code
@@ -219,6 +220,20 @@ a new set of recovery codes with SSH:
 After signing in, visit your **Profile settings > Account**  immediately to set
 up two-factor authentication with a new device.
+### Regenerate 2FA recovery codes
+
+To regenerate 2FA recovery codes, you need access to a desktop browser:
+
+1. Navigate to GitLab.
+1. Sign in to your GitLab account.
+1. Go to your [Profile settings](../index.md#profile-settings).
+1. Select **{account}** **Account > Two-Factor Authentication (2FA)**.
+1. If you've already configured 2FA, click **Manage two-factor authentication**.
+1. In the **Register Two-Factor Authenticator** pane, click **Regenerate recovery codes**.
+
+NOTE: **Note:**
+If you regenerate 2FA recovery codes, save them. You won't be able to use any previously created 2FA codes.
+
 ### Ask a GitLab administrator to disable two-factor authentication on your account
 If you cannot use a saved recovery code or generate new recovery codes, ask a

doc/user/project/clusters/add_remove_clusters.md

@@ -5,7 +5,7 @@ GitLab offers integrated cluster creation for the following Kubernetes providers
 - Google Kubernetes Engine (GKE).
 - Amazon Elastic Kubernetes Service (EKS).
-In addition, GitLab can integrate with any standard Kubernetes provider, either on-premise or hosted.
+GitLab can also integrate with any standard Kubernetes provider, either on-premise or hosted.
 TIP: **Tip:**
 Every new Google Cloud Platform (GCP) account receives [$300 in credit upon sign up](https://console.cloud.google.com/freetrial),

doc/user/project/import/github.md

@@ -40,10 +40,13 @@ in which case it defaults to the default project visibility.
 When issues and pull requests are being imported, the importer attempts to find their GitHub authors and
 assignees in the database of the GitLab instance (note that pull requests are called "merge requests" in GitLab).
-For this association to succeed, prior to the import, each GitHub author and assignee in the repository must
-have either previously logged in to a GitLab account using the GitHub icon **or** have a GitHub account with
-a [primary email address](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address) that
-matches their GitLab account's email address.
+For this association to succeed, each GitHub author and assignee in the repository
+must meet one of the following conditions prior to the import:
+
+- Have previously logged in to a GitLab account using the GitHub icon.
+- Have a GitHub account with a
+  [primary email address](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/setting-your-commit-email-address)
+  that matches their GitLab account's email address.
 If a user referenced in the project is not found in GitLab's database, the project creator (typically the user
 that initiated the import process) is set as the author/assignee, but a note on the issue mentioning the original

doc/user/project/import/index.md

@@ -24,7 +24,7 @@ There is also the option of [connecting your external repository to get CI/CD be
 ## Migrating from self-hosted GitLab to GitLab.com
-If you only need to migrate Git repos, you can [import each project by URL](repo_by_url.md), but issues and merge requests can't be imported.
+If you only need to migrate Git repos, you can [import each project by URL](repo_by_url.md). Issues and merge requests can't be imported.
 If you want to retain all metadata like issues and merge requests, you can use
 the [import/export feature](../settings/import_export.md) to export projects from self-hosted GitLab and import those projects into GitLab.com.

doc/user/project/index.md

@@ -94,7 +94,7 @@ When you create a project in GitLab, you'll have access to a large number of
   your code blocks, overriding GitLab's default choice of language.
 - [Badges](badges.md): badges for the project overview.
 - [Releases](releases/index.md): a way to track deliverables in your project as snapshot in time of
-  the source, build output, and other metadata or artifacts
+  the source, build output, other metadata, and other artifacts
   associated with a released version of your code.
 - [Conan packages](../packages/conan_repository/index.md): your private Conan repository in GitLab. **(PREMIUM)**
 - [Maven packages](../packages/maven_repository/index.md): your private Maven repository in GitLab. **(PREMIUM)**

doc/user/project/integrations/jira.md

@@ -45,11 +45,11 @@ In order to enable the Jira service in GitLab, you need to first configure the p
 #### Jira Server
-When connecting to **Jira Server**, which supports basic authentication, a **username and password** are required. Note that connecting to Jira Server via CAS is not possible. [Set up a user in Jira Server](jira_server_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
+**Jira Server** supports basic authentication. When connecting, a **username and password** are required. Note that connecting to Jira Server via CAS is not possible. [Set up a user in Jira Server](jira_server_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
 #### Jira Cloud
-When connecting to **Jira Cloud**, which supports authentication via API token, an **email and API token**, are required. [Set up a user in Jira Cloud](jira_cloud_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
+**Jira Cloud** supports authentication through an API token. When connecting to **Jira Cloud**, an **email and API token** are required. [Set up a user in Jira Cloud](jira_cloud_configuration.md) first and then proceed to [Configuring GitLab](#configuring-gitlab).
 ### Configuring GitLab

lib/gitlab/sidekiq_middleware.rb

@@ -9,18 +9,18 @@ module Gitlab
     # eg: `config.server_middleware(&Gitlab::SidekiqMiddleware.server_configurator)`
     def self.server_configurator(metrics: true, arguments_logger: true, memory_killer: true, request_store: true)
       lambda do |chain|
-        chain.add Gitlab::SidekiqMiddleware::Monitor
-        chain.add Gitlab::SidekiqMiddleware::ServerMetrics if metrics
-        chain.add Gitlab::SidekiqMiddleware::ArgumentsLogger if arguments_logger
-        chain.add Gitlab::SidekiqMiddleware::MemoryKiller if memory_killer
-        chain.add Gitlab::SidekiqMiddleware::RequestStoreMiddleware if request_store
-        chain.add Gitlab::SidekiqMiddleware::BatchLoader
-        chain.add Labkit::Middleware::Sidekiq::Server
-        chain.add Gitlab::SidekiqMiddleware::InstrumentationLogger
-        chain.add Gitlab::SidekiqMiddleware::AdminMode::Server
-        chain.add Gitlab::SidekiqStatus::ServerMiddleware
-        chain.add Gitlab::SidekiqMiddleware::WorkerContext::Server
-        chain.add Gitlab::SidekiqMiddleware::DuplicateJobs::Server
+        chain.add ::Gitlab::SidekiqMiddleware::Monitor
+        chain.add ::Gitlab::SidekiqMiddleware::ServerMetrics if metrics
+        chain.add ::Gitlab::SidekiqMiddleware::ArgumentsLogger if arguments_logger
+        chain.add ::Gitlab::SidekiqMiddleware::MemoryKiller if memory_killer
+        chain.add ::Gitlab::SidekiqMiddleware::RequestStoreMiddleware if request_store
+        chain.add ::Gitlab::SidekiqMiddleware::BatchLoader
+        chain.add ::Labkit::Middleware::Sidekiq::Server
+        chain.add ::Gitlab::SidekiqMiddleware::InstrumentationLogger
+        chain.add ::Gitlab::SidekiqMiddleware::AdminMode::Server
+        chain.add ::Gitlab::SidekiqStatus::ServerMiddleware
+        chain.add ::Gitlab::SidekiqMiddleware::WorkerContext::Server
+        chain.add ::Gitlab::SidekiqMiddleware::DuplicateJobs::Server
       end
     end
@@ -29,12 +29,12 @@ module Gitlab
     # eg: `config.client_middleware(&Gitlab::SidekiqMiddleware.client_configurator)`
     def self.client_configurator
       lambda do |chain|
-        chain.add Gitlab::SidekiqStatus::ClientMiddleware
-        chain.add Gitlab::SidekiqMiddleware::ClientMetrics
-        chain.add Gitlab::SidekiqMiddleware::WorkerContext::Client # needs to be before the Labkit middleware
-        chain.add Labkit::Middleware::Sidekiq::Client
-        chain.add Gitlab::SidekiqMiddleware::AdminMode::Client
-        chain.add Gitlab::SidekiqMiddleware::DuplicateJobs::Client
+        chain.add ::Gitlab::SidekiqStatus::ClientMiddleware
+        chain.add ::Gitlab::SidekiqMiddleware::ClientMetrics
+        chain.add ::Gitlab::SidekiqMiddleware::WorkerContext::Client # needs to be before the Labkit middleware
+        chain.add ::Labkit::Middleware::Sidekiq::Client
+        chain.add ::Gitlab::SidekiqMiddleware::AdminMode::Client
+        chain.add ::Gitlab::SidekiqMiddleware::DuplicateJobs::Client
       end
     end
   end