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

doc/user/admin_area/settings/visibility_and_access_controls.md

@@ -15,7 +15,7 @@ To access the visibility and access control options:
 ## Default branch protection
 
 This global option defines the branch protection that applies to every repository's default branch. [Branch protection](../../project/protected_branches.md) specifies which roles can push to branches and which roles can delete
-branches.  In this case _Default_ refers to a repository's default branch, which in most cases is _master_.
+branches. In this case _Default_ refers to a repository's default branch, which in most cases is _master_.
 
 This setting applies only to each repositories' default branch. To protect other branches, you must configure branch protection in repository. For details, see [Protected Branches](../../project/protected_branches.md).
 

doc/user/application_security/container_scanning/index.md

@@ -170,7 +170,7 @@ using environment variables.
 | `DOCKER_PASSWORD`              | Password for accessing a Docker registry requiring authentication.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | `$CI_REGISTRY_PASSWORD`                  |
 | `CLAIR_OUTPUT`                 | Severity level threshold. Vulnerabilities with severity level higher than or equal to this threshold will be outputted. Supported levels are `Unknown`, `Negligible`, `Low`, `Medium`, `High`, `Critical` and `Defcon1`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      | `Unknown`                                |
 | `REGISTRY_INSECURE`            | Allow [Klar](https://github.com/optiopay/klar) to access insecure registries (HTTP only). Should only be set to `true` when testing the image locally.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        | `"false"`                                |
-| `CLAIR_VULNERABILITIES_DB_URL` | This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/blob/30522ca8b901223ac8c32b633d8d67f340b159c1/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L17-19) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`.  This value represents the address that the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the scanning tool](https://gitlab.com/gitlab-org/security-products/analyzers/klar/#running-the-scanning-tool) section of the [GitLab klar analyzer readme](https://gitlab.com/gitlab-org/security-products/analyzers/klar). | `clair-vulnerabilities-db`               |
+| `CLAIR_VULNERABILITIES_DB_URL` | This variable is explicitly set in the [services section](https://gitlab.com/gitlab-org/gitlab/blob/30522ca8b901223ac8c32b633d8d67f340b159c1/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml#L17-19) of the `Container-Scanning.gitlab-ci.yml` file and defaults to `clair-vulnerabilities-db`. This value represents the address that the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db) is running on and **shouldn't be changed** unless you're running the image locally as described in the [Running the scanning tool](https://gitlab.com/gitlab-org/security-products/analyzers/klar/#running-the-scanning-tool) section of the [GitLab klar analyzer readme](https://gitlab.com/gitlab-org/security-products/analyzers/klar). | `clair-vulnerabilities-db`               |
 | `CI_APPLICATION_REPOSITORY`    | Docker repository URL for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | `$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG` |
 | `CI_APPLICATION_TAG`           | Docker respository tag for the image to be scanned.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           | `$CI_COMMIT_SHA`                         |
 | `CLAIR_DB_IMAGE`               | The Docker image name and tag for the [postgres server hosting the vulnerabilities definitions](https://hub.docker.com/r/arminc/clair-db). It can be useful to override this value with a specific version, for example, to provide a consistent set of vulnerabilities for integration testing purposes, or to refer to a locally hosted vulnerabilities database for an on-premise air-gapped installation.                                                                                                                                                                                                                                                                                                                                                                                                 | `arminc/clair-db:latest`                 |
@@ -211,7 +211,7 @@ Container Scanning can be executed on an offline air-gapped GitLab Ultimate inst
        CLAIR_DB_IMAGE: $CI_REGISTRY/namespace/clair-vulnerabilities-db
    ```
 
-It may be worthwhile to set up a [scheduled pipeline](../../project/pipelines/schedules.md) to automatically build a new version of the vulnerabilities database on a preset schedule.  You can use the following `.gitlab-yml.ci` as a template:
+It may be worthwhile to set up a [scheduled pipeline](../../project/pipelines/schedules.md) to automatically build a new version of the vulnerabilities database on a preset schedule. You can use the following `.gitlab-yml.ci` as a template:
 
 ```yaml
 image: docker:stable

doc/user/application_security/dependency_scanning/index.md

@@ -64,7 +64,7 @@ The following languages and dependency managers are supported.
 | Python ([poetry](https://poetry.eustace.io/)) | not currently ([issue](https://gitlab.com/gitlab-org/gitlab/issues/7006 "Support Poetry in Dependency Scanning")) | not available |
 | Ruby ([gem](https://rubygems.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium), [bundler-audit](https://github.com/rubysec/bundler-audit) |
 | Scala ([sbt](https://www.scala-sbt.org/)) | yes | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
-| Go ([Golang](https://golang.org/)) | yes ([alpha](https://gitlab.com/gitlab-org/gitlab/issues/7132)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
+| Go ([Go Modules](https://github.com/golang/go/wiki/Modules)) | yes ([alpha](https://gitlab.com/gitlab-org/gitlab/issues/7132)) | [gemnasium](https://gitlab.com/gitlab-org/security-products/gemnasium) |
 
 ## Configuration
 

doc/user/application_security/index.md

@@ -118,7 +118,7 @@ Some vulnerabilities can be fixed by applying the solution that GitLab
 automatically generates. The following scanners are supported:
 
 - [Dependency Scanning](dependency_scanning/index.md):
-  Automatic Patch creation is only available for Node.JS projects managed with
+  Automatic Patch creation is only available for Node.js projects managed with
   `yarn`.
 
 #### Manually applying the suggested patch

doc/user/application_security/security_dashboard/index.md

@@ -112,7 +112,7 @@ Read more on how to [interact with the vulnerabilities](../index.md#interacting-
 
 ## Instance Security Dashboard
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6953) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/6953) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.8.
 
 At the instance level, the Security Dashboard displays the vulnerabilities
 present in all of the projects that you have added to it.

doc/user/gitlab_com/index.md

@@ -218,8 +218,11 @@ You can follow our work towards this goal in the
 
 The full contents of our `config.toml` are:
 
+NOTE: **Note:**
+Settings that are not public are shown as `X`.
+
 ```toml
-concurrent = 10
+concurrent = X
 check_interval = 3
 
 [[runners]]
@@ -291,8 +294,8 @@ stages:
   - test
 
 before_script:
- - date +"%H"
- - echo ${HOUR}
+ - Set-Variable -Name "time" -Value (date -Format "%H:%m")
+ - echo ${time}
  - echo "started by ${GITLAB_USER_NAME}"
 
 build:

doc/user/markdown.md

@@ -964,7 +964,7 @@ Here's a sample audio clip:
 You can also use raw HTML in your Markdown, and it'll usually work pretty well.
 
 See the documentation for HTML::Pipeline's [SanitizationFilter](https://www.rubydoc.info/gems/html-pipeline/1.11.0/HTML/Pipeline/SanitizationFilter#WHITELIST-constant)
-class for the list of allowed HTML tags and attributes.  In addition to the default
+class for the list of allowed HTML tags and attributes. In addition to the default
 `SanitizationFilter` whitelist, GitLab allows `span`, `abbr`, `details` and `summary` elements.
 
 ```html

doc/user/packages/npm_registry/index.md

@@ -37,7 +37,7 @@ the [next section](#authenticating-to-the-gitlab-npm-registry).
 
 ### Installing NPM
 
-Follow the instructions at [npmjs.com](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to download and install Node.JS and
+Follow the instructions at [npmjs.com](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) to download and install Node.js and
 NPM to your local development environment.
 
 Once installation is complete, verify you can use NPM in your terminal by

doc/user/project/clusters/serverless/index.md

@@ -349,7 +349,7 @@ The optional `runtime` parameter can refer to one of the following runtime alias
 
 After the `gitlab-ci.yml` template has been added and the `serverless.yml` file
 has been created, pushing a commit to your project will result in a CI pipeline
-being executed which will deploy each function as a Knative service.  Once the
+being executed which will deploy each function as a Knative service. Once the
 deploy stage has finished, additional details for the function will appear
 under **Operations > Serverless**.
 

doc/user/project/highlighting.md

@@ -10,7 +10,7 @@ If GitLab is guessing wrong, you can override its choice of language using the `
 
 When you check in and push that change, all `*.pl` files in your project will be highlighted as Prolog.
 
-The paths here are simply Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes).  So, if you were to invent a file format called a `Nicefile` at the root of your project that used ruby syntax, all you need is:
+The paths here are simply Git's built-in [`.gitattributes` interface](https://git-scm.com/docs/gitattributes). So, if you were to invent a file format called a `Nicefile` at the root of your project that used ruby syntax, all you need is:
 
 ``` conf
 /Nicefile gitlab-language=ruby

doc/user/project/import/bitbucket_server.md

@@ -48,7 +48,7 @@ The Bitbucket Server importer works as follows:
 
 When issues/pull requests are being imported, the Bitbucket importer tries to
 find the author's e-mail address with a confirmed e-mail address in the GitLab
-user database.  If no such user is available, the project creator is set as
+user database. If no such user is available, the project creator is set as
 the author. The importer will append a note in the comment to mark the original
 creator.
 

doc/user/project/integrations/irker.md

@@ -47,7 +47,7 @@ Irker accepts channel names of the form `chan` and `#chan`, both for the
 case, `Aorimn` is treated as a nick and no more as a channel name.
 
 Irker can also join password-protected channels. Users need to append
-`?key=thesecretpassword` to the chan name.  When using this feature remember to
+`?key=thesecretpassword` to the chan name. When using this feature remember to
 **not** put the `#` sign in front of the channel name; failing to do so will
 result on irker joining a channel literally named `#chan?key=password` henceforth
 leaking the channel key through the `/whois` IRC command (depending on IRC server

doc/user/project/integrations/webhooks.md

@@ -1364,7 +1364,7 @@ server.start
 ```
 
 Pick an unused port (e.g. 8000) and start the script: `ruby print_http_body.rb
-8000`.  Then add your server as a webhook receiver in GitLab as
+8000`. Then add your server as a webhook receiver in GitLab as
 `http://my.host:8000/`.
 
 When you press 'Test' in GitLab, you should see something like this in the

doc/user/project/issues/sorting_issue_lists.md

@@ -19,7 +19,7 @@ order with respect to the other issues in the list. When you drag-and-drop reord
 an issue, its relative order value changes accordingly.
 
 In addition, any time that issue appears in a manually sorted list,
-the updated relative order value will be used for the ordering.  This means that
+the updated relative order value will be used for the ordering. This means that
 if issue `A` is drag-and-drop reordered to be above issue `B` by any user in
 a given list inside your GitLab instance, any time those two issues are subsequently
 loaded in any list in the same instance (could be a different project issue list or a

doc/user/project/members/share_project_with_groups.md

@@ -13,7 +13,7 @@ members.
 
 The primary mechanism to give a group of users, say 'Engineering', access to a project,
 say 'Project Acme', in GitLab is to make the 'Engineering' group the owner of 'Project
-Acme'.  But what if 'Project Acme' already belongs to another group, say 'Open Source'?
+Acme'. But what if 'Project Acme' already belongs to another group, say 'Open Source'?
 This is where the group sharing feature can be of use.
 
 To share 'Project Acme' with the 'Engineering' group:

doc/user/project/merge_requests/merge_request_dependencies.md

@@ -4,13 +4,9 @@ type: reference, concepts
 
 # Merge Request dependencies **(PREMIUM)**
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9688) in
-[GitLab Premium](https://about.gitlab.com/pricing/) 12.2.
-> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17291) from
-"Cross-project dependencies" to "Merge Requests dependencies" in
-[GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
-> - Intra-project MR dependencies were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16799)
-in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/9688) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.2.
+> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/17291) from "Cross-project dependencies" to "Merge Requests dependencies" in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
+> - Intra-project MR dependencies were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/16799) in [GitLab Premium](https://about.gitlab.com/pricing/) 12.4.
 
 Merge request dependencies allows a required order of merging
 between merge requests to be expressed. If a merge request "depends on" another,
@@ -129,7 +125,7 @@ graph LR;
     herfriend/another-lib!1-->mycorp/awesome-project!100;
 ```
 
-What is **not** supported is a "deep", or "nested" graph of dependencies, e.g.:
+What is **not** supported is a "deep", or "nested" graph of dependencies. For example:
 
 ```mermaid
 graph LR;

doc/user/project/repository/gpg_signed_commits/index.md

@@ -54,7 +54,7 @@ started:
    In some cases like Gpg4win on Windows and other macOS versions, the command
    here may be `gpg --gen-key`.
 
-1. The first question is which algorithm can be used.  Select the kind you want
+1. The first question is which algorithm can be used. Select the kind you want
    or press <kbd>Enter</kbd> to choose the default (RSA and RSA):
 
    ```plaintext