Add latest changes from gitlab-org/gitlab@master

.vale.ini

@@ -38,12 +38,3 @@ BasedOnStyles = gitlab
 # To change the reporting level (suggestion, warning, error) of a rule,
 # use the following format: {style}.{filename} = {level}
 # vale.Hedging = error
-
-# Syntax-specific settings
-# ------------------------
-# You can configure specific tests to be enabled, disabled, or report at a 
-# different level for specific file types. File-type-specific settings added
-# here will overwrite any conflicting global settings.
-[*.{md,txt}]
-# vale.Editorializing = NO
-

doc/administration/geo/replication/troubleshooting.md

@@ -242,7 +242,7 @@ sudo gitlab-rake gitlab:geo:check
     Checking Geo ... Finished
     ```
-    When performing a Postgres major version (9 > 10) update this is expected.  Follow:
+    When performing a Postgres major version (9 > 10) update this is expected. Follow:
     - [initiate-the-replication-process](https://docs.gitlab.com/ee/administration/geo/replication/database.html#step-3-initiate-the-replication-process)
     - [Geo database has an outdated FDW remote schema](https://docs.gitlab.com/ee/administration/geo/replication/troubleshooting.html#geo-database-has-an-outdated-fdw-remote-schema-error)

doc/administration/instance_limits.md

@@ -108,7 +108,7 @@ Reports that go over the 20 MB limit won't be loaded. Affected reports:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/201826) in GitLab 12.8.
 You can set a limit on the content of text fields indexed for Global Search.
-Setting a maximum helps to reduce the load of the indexing processes.  If any
+Setting a maximum helps to reduce the load of the indexing processes. If any
 text field exceeds this limit then the text will be truncated to this number of
 characters and the rest will not be indexed and hence will not be searchable.

doc/administration/invalidate_markdown_cache.md

@@ -7,7 +7,7 @@ when the `external_url` configuration option is changed - causing links
 in the cached text to refer to the old URL.
 To avoid this problem, the administrator can invalidate the existing cache by
-increasing the `local_markdown_version` setting in application settings.  This can
+increasing the `local_markdown_version` setting in application settings. This can
 be done by [changing the application settings through
 the API](../api/settings.md#change-application-settings):

doc/api/README.md

@@ -449,7 +449,7 @@ GET /api/v4/projects/diaspora%2Fdiaspora
 ```
 NOTE: **Note:**
-A project's **path** is not necessarily the same as its **name**.  A
+A project's **path** is not necessarily the same as its **name**. A
 project's path can be found in the project's URL or in the project's settings
 under **General > Advanced > Change path**.

doc/api/users.md

@@ -1168,7 +1168,7 @@ Will return `201 OK` on success, `404 User Not Found` is user cannot be found or
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/22257) in GitLab 12.4.
-Deactivates the specified user.  Available only for admin.
+Deactivates the specified user. Available only for admin.
 ```
 POST /users/:id/deactivate
@@ -1190,7 +1190,7 @@ Returns:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/22257) in GitLab 12.4.
-Activates the specified user.  Available only for admin.
+Activates the specified user. Available only for admin.
 ```
 POST /users/:id/activate

doc/ci/docker/using_docker_images.md

@@ -642,7 +642,7 @@ Specifying only `registry.example.com` will not work.
 ### Configuring a Runner
 If you have many pipelines that access the same registry, it'll
-probably be better to setup registry access at the runner level.  This
+probably be better to setup registry access at the runner level. This
 allows pipeline authors to have access to a private registry just by
 running a job on the appropriate runner. It also makes registry
 changes and credential rotations much simpler.

doc/ci/variables/predefined_variables.md

@@ -99,7 +99,7 @@ future GitLab releases.**
 | `CI_PROJECT_TITLE`                            | 12.4   | all    | The human-readable project name as displayed in the GitLab web interface.                                                                                                                                                                                                                                                                                  |
 | `CI_PROJECT_URL`                              | 8.10   | 0.5    | The HTTP(S) address to access project                                                                                                                                                                                                                                                                                                                      |
 | `CI_PROJECT_VISIBILITY`                       | 10.3   | all    | The project visibility (internal, private, public)                                                                                                                                                                                                                                                                                                         |
-| `CI_REGISTRY`                                 | 8.10   | 0.5    | If the Container Registry is enabled it returns the address of GitLab's Container Registry.  This variable will include a `:port` value if one has been specified in the registry configuration.                                                                                                                                                           |
+| `CI_REGISTRY`                                 | 8.10   | 0.5    | If the Container Registry is enabled it returns the address of GitLab's Container Registry. This variable will include a `:port` value if one has been specified in the registry configuration.                                                                                                                                                           |
 | `CI_REGISTRY_IMAGE`                           | 8.10   | 0.5    | If the Container Registry is enabled for the project it returns the address of the registry tied to the specific project                                                                                                                                                                                                                                   |
 | `CI_REGISTRY_PASSWORD`                        | 9.0    | all    | The password to use to push containers to the GitLab Container Registry                                                                                                                                                                                                                                                                                    |
 | `CI_REGISTRY_USER`                            | 9.0    | all    | The username to use to push containers to the GitLab Container Registry                                                                                                                                                                                                                                                                                    |

doc/ci/yaml/README.md

@@ -1523,7 +1523,7 @@ globally and all jobs will use that definition.
 Use the `paths` directive to choose which files or directories will be cached. Paths
 are relative to the project directory (`$CI_PROJECT_DIR`) and cannot directly link outside it.
 Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming))
-patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match).
+patterns and [`filepath.Match`](https://golang.org/pkg/path/filepath/#Match).
 Cache all files in `binaries` that end in `.apk` and the `.config` file:
@@ -1755,7 +1755,7 @@ be available for download in the GitLab UI.
 Paths are relative to the project directory (`$CI_PROJECT_DIR`) and cannot directly
 link outside it. Wildcards can be used that follow the [glob](https://en.wikipedia.org/wiki/Glob_(programming))
-patterns and [filepath.Match](https://golang.org/pkg/path/filepath/#Match).
+patterns and [`filepath.Match`](https://golang.org/pkg/path/filepath/#Match).
 To restrict which jobs a specific job will fetch artifacts from, see [dependencies](#dependencies).
@@ -3212,9 +3212,9 @@ spinach:
 ```
 In GitLab 12.0 and later, it's also possible to use multiple parents for
-`extends`.  The algorithm used for merge is "closest scope wins", so
+`extends`. The algorithm used for merge is "closest scope wins", so
 keys from the last member will always shadow anything defined on other
-levels.  For example:
+levels. For example:
 ```yaml
 .only-important:

doc/development/api_graphql_styleguide.md

@@ -180,8 +180,8 @@ query($project_path: ID!) {
 ```
 To ensure that we get consistent ordering, we will append an ordering on the primary
-key, in descending order.  This is usually `id`, so basically we will add `order(id: :desc)`
-to the end of the relation.  A primary key _must_ be available on the underlying table.
+key, in descending order. This is usually `id`, so basically we will add `order(id: :desc)`
+to the end of the relation. A primary key _must_ be available on the underlying table.
 ### Exposing permissions for a type

doc/development/emails.md

@@ -79,17 +79,17 @@ See the [Rails guides](https://guides.rubyonrails.org/action_mailer_basics.html#
 ## Email namespace
-As of GitLab 11.7, we support a new format for email handler addresses.  This was done to
+As of GitLab 11.7, we support a new format for email handler addresses. This was done to
 support catch-all mailboxes.
 If you need to implement a feature which requires a new email handler, follow these rules
 for the format of the email key:
-- Actions are always at the end, separated by `-`.  For example `-issue` or `-merge-request`
+- Actions are always at the end, separated by `-`. For example `-issue` or `-merge-request`
 - If your feature is related to a project, the key begins with the project identifiers (project path slug
-  and project id), separated by `-`.  For example, `gitlab-org-gitlab-foss-20`
+  and project id), separated by `-`. For example, `gitlab-org-gitlab-foss-20`
 - Additional information, such as an author's token, can be added between the project identifiers and
-  the action, separated by `-`.  For example, `gitlab-org-gitlab-foss-20-Author_Token12345678-issue`
+  the action, separated by `-`. For example, `gitlab-org-gitlab-foss-20-Author_Token12345678-issue`
 - You register your handlers in `lib/gitlab/email/handler.rb`
 Examples of valid email keys:

doc/development/go_guide/index.md

@@ -40,7 +40,7 @@ of possible security breaches in our code:
 - SQL injections
 Remember to run
-[SAST](../../user/application_security/sast/index.md)
+[SAST](../../user/application_security/sast/index.md) and [Dependency Scanning](../../user/application_security/dependency_scanning/index.md)
 **(ULTIMATE)** on your project (or at least the [gosec
 analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)),
 and to follow our [Security

doc/integration/elasticsearch.md

@@ -466,13 +466,13 @@ When performing a search, the GitLab index will use the following scopes:
 ### Deleted documents
-Whenever a change or deletion is made to an indexed GitLab object (a merge request description is changed, a file is deleted from the master branch in a repository, a project is deleted, etc), a document in the index is deleted.  However, since these are "soft" deletes, the overall number of "deleted documents", and therefore wasted space, increases.  Elasticsearch does intelligent merging of segments in order to remove these deleted documents.  However, depending on the amount and type of activity in your GitLab installation, it's possible to see as much as 50% wasted space in the index.
+Whenever a change or deletion is made to an indexed GitLab object (a merge request description is changed, a file is deleted from the master branch in a repository, a project is deleted, etc), a document in the index is deleted. However, since these are "soft" deletes, the overall number of "deleted documents", and therefore wasted space, increases. Elasticsearch does intelligent merging of segments in order to remove these deleted documents. However, depending on the amount and type of activity in your GitLab installation, it's possible to see as much as 50% wasted space in the index.
 In general, we recommend simply letting Elasticsearch merge and reclaim space automatically, with the default settings. From [Lucene's Handling of Deleted Documents](https://www.elastic.co/blog/lucenes-handling-of-deleted-documents "Lucene's Handling of Deleted Documents"), _"Overall, besides perhaps decreasing the maximum segment size, it is best to leave Lucene's defaults as-is and not fret too much about when deletes are reclaimed."_
 However, some larger installations may wish to tune the merge policy settings:
-- Consider reducing the `index.merge.policy.max_merged_segment` size from the default 5 GB to maybe 2 GB or 3 GB.  Merging only happens when a segment has at least 50% deletions.  Smaller segment sizes will allow merging to happen more frequently.
+- Consider reducing the `index.merge.policy.max_merged_segment` size from the default 5 GB to maybe 2 GB or 3 GB. Merging only happens when a segment has at least 50% deletions. Smaller segment sizes will allow merging to happen more frequently.
   ```shell
   curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' --data '{
@@ -482,7 +482,7 @@ However, some larger installations may wish to tune the merge policy settings:
   }'
   ```
-- You can also adjust `index.merge.policy.reclaim_deletes_weight`, which controls how aggressively deletions are targeted.  But this can lead to costly merge decisions, so we recommend not changing this unless you understand the tradeoffs.
+- You can also adjust `index.merge.policy.reclaim_deletes_weight`, which controls how aggressively deletions are targeted. But this can lead to costly merge decisions, so we recommend not changing this unless you understand the tradeoffs.
   ```shell
   curl --request PUT localhost:9200/gitlab-production/_settings ---header 'Content-Type: application/json' --data '{
@@ -492,7 +492,7 @@ However, some larger installations may wish to tune the merge policy settings:
   }'
   ```
-- Do not do a [force merge](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") to remove deleted documents.  A warning in the [documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") states that this can lead to very large segments that may never get reclaimed, and can also cause significant performance or availability issues.
+- Do not do a [force merge](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") to remove deleted documents. A warning in the [documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-forcemerge.html "Force Merge") states that this can lead to very large segments that may never get reclaimed, and can also cause significant performance or availability issues.
 ## Troubleshooting

doc/integration/saml.md

@@ -243,7 +243,7 @@ considered `admin groups`.
 >**Note:**
 This setting is only available on GitLab 11.4 EE and above.
-This setting also follows the requirements documented for the `External Groups` setting.  GitLab uses the Group information provided by your IdP to determine if a user should be assigned the `auditor` role.
+This setting also follows the requirements documented for the `External Groups` setting. GitLab uses the Group information provided by your IdP to determine if a user should be assigned the `auditor` role.
 ```yaml
 { name: 'saml',
@@ -374,7 +374,7 @@ in the OmniAuth [info hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash-
 For example, if your SAMLResponse contains an Attribute called 'EmailAddress',
 specify `{ email: ['EmailAddress'] }` to map the Attribute to the
-corresponding key in the info hash.  URI-named Attributes are also supported, e.g.
+corresponding key in the info hash. URI-named Attributes are also supported, e.g.
 `{ email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }`.
 This setting allows you tell GitLab where to look for certain attributes required

doc/integration/vault.md

@@ -65,7 +65,7 @@ The following assumes you already have Vault installed and running.
 1. **Write the OIDC Role Config:**
-    Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`.  Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
+    Now that Vault has a GitLab application ID and secret, it needs to know the [**Redirect URIs**](https://www.vaultproject.io/docs/auth/jwt.html#redirect-uris) and scopes given to GitLab during the application creation process. The redirect URIs need to match where your Vault instance is running. The `oidc_scopes` field needs to include the `openid`. Similarly to the previous step, replace `your_application_id` with the generated application ID from GitLab:
     This configuration is saved under the name of the role you are creating. In this case, we are creating a `demo` role. Later, we'll show how you can access this role through the Vault CLI.

doc/migrate_ci_to_ce/README.md

@@ -129,7 +129,7 @@ First upgrade your GitLab server to version 8.0:
 ### 2. Disable CI on the GitLab server during the migration
-After you update, go to the admin panel and temporarily disable CI.  As
+After you update, go to the admin panel and temporarily disable CI. As
   an administrator, go to **Admin Area** -> **Settings**, and under
 **Continuous Integration** uncheck **Disable to prevent CI usage until rake
 ci:migrate is run (8.0 only)**.

doc/raketasks/backup_restore.md

@@ -728,7 +728,7 @@ This procedure assumes that:
 - You have installed the **exact same version and type (CE/EE)** of GitLab
   Omnibus with which the backup was created.
 - You have run `sudo gitlab-ctl reconfigure` at least once.
-- GitLab is running.  If not, start it using `sudo gitlab-ctl start`.
+- GitLab is running. If not, start it using `sudo gitlab-ctl start`.
 First make sure your backup tar file is in the backup directory described in the
 `gitlab.rb` configuration `gitlab_rails['backup_path']`. The default is
@@ -739,7 +739,7 @@ sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backu
 sudo chown git.git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar
 ```
-Stop the processes that are connected to the database.  Leave the rest of GitLab
+Stop the processes that are connected to the database. Leave the rest of GitLab
 running:
 ```shell

doc/raketasks/list_repos.md

@@ -13,7 +13,7 @@ sudo -u git -H bundle exec rake gitlab:list_repos RAILS_ENV=production
 ```
 If you only want to list projects with recent activity you can pass
-a date with the 'SINCE' environment variable.  The time you specify
+a date with the 'SINCE' environment variable. The time you specify
 is parsed by the Rails [TimeZone#parse
 function](https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse).

doc/ssh/README.md

@@ -368,7 +368,7 @@ be configured on any repository in the entire GitLab installation.
 This is really useful for integrating repositories to secured, shared Continuous
 Integration (CI) services or other shared services.
 GitLab administrators can set up the Global Shared Deploy key in GitLab and
-add the private key to any shared systems.  Individual repositories opt into
+add the private key to any shared systems. Individual repositories opt into
 exposing their repository using these keys when a project maintainers (or higher)
 authorizes a Global Shared Deploy key to be used with their project.

doc/user/admin_area/settings/usage_statistics.md

@@ -30,7 +30,7 @@ This information is used, among other things, to identify to which versions
 patches will need to be backported, making sure active GitLab instances remain
 secure.
-If you disable version check, this information will not be collected.  Enable or
+If you disable version check, this information will not be collected. Enable or
 disable the version check in **Admin Area > Settings > Metrics and profiling > Usage statistics**.
 ### Request flow example