Add latest changes from gitlab-org/gitlab@master

18 files changed, 46 insertions, 46 deletions

diff --git a/doc/administration/auth/ldap-troubleshooting.md b/doc/administration/auth/ldap-troubleshooting.md
index c97231793db..ded5153133d 100644
--- a/doc/administration/auth/ldap-troubleshooting.md
+++ b/doc/administration/auth/ldap-troubleshooting.md
@@ -311,7 +311,7 @@ things to check to debug the situation.
 - You've waited an hour or [the configured
   interval](ldap-ee.md#adjusting-ldap-group-sync-schedule) for the group to
   sync. To speed up the process, either go to the GitLab group **Settings ->
-  Members** and press **Sync now** (sync one group) or [run the group sync rake
+  Members** and press **Sync now** (sync one group) or [run the group sync Rake
   task][group-sync-rake] (sync all groups).
 
 If all of the above looks good, jump in to a little more advanced debugging in
@@ -351,7 +351,7 @@ GitLab syncs the `admin_group`.
 #### Sync all groups **(STARTER ONLY)**
 
 NOTE: **NOTE:**
-To sync all groups manually when debugging is unnecessary, [use the rake
+To sync all groups manually when debugging is unnecessary, [use the Rake
 task][group-sync-rake] instead.
 
 The output from a manual [group sync][group-sync] can show you what happens
@@ -541,7 +541,7 @@ for each of these users.
 
 ### LDAP check
 
-The [rake task to check LDAP][ldap-check] is a valuable tool
+The [Rake task to check LDAP][ldap-check] is a valuable tool
 to help determine whether GitLab can successfully establish a connection to
 LDAP and can get so far as to even read users.
 
@@ -550,7 +550,7 @@ with your configuration or a firewall blocking the connection.
 
 - Ensure you don't have a firewall blocking the
 connection, and that the LDAP server is accessible to the GitLab host.
-- Look for an error message in the rake check output, which may lead to your LDAP configuration to
+- Look for an error message in the Rake check output, which may lead to your LDAP configuration to
 confirm that the configuration values (specifically `host`, `port`, `bind_dn`, and
 `password`) are correct.
 - Look for [errors](#connection) in [the logs](#gitlab-logs) to further debug connection failures.
diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
index dbcc37b25e7..60bfca74b6b 100644
--- a/doc/administration/file_hooks.md
+++ b/doc/administration/file_hooks.md
@@ -88,9 +88,9 @@ end
 ## Validation
 
 Writing your own file hook can be tricky and it's easier if you can check it
-without altering the system. A rake task is provided so that you can use it
+without altering the system. A Rake task is provided so that you can use it
 in a staging environment to test your file hook before using it in production.
-The rake task will use a sample data and execute each of file hook. The output
+The Rake task will use a sample data and execute each of file hook. The output
 should be enough to determine if the system sees your file hook and if it was
 executed without errors.
 
diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index 6852d08cc07..fe55539dc84 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -115,7 +115,7 @@ Feature.enable('geo_repository_reverification')
 
 Geo actively try to correct verification failures marking the repository to
 be resynced with a back-off period. If you want to reset them manually, this
-rake task marks projects where verification has failed or the checksum mismatch
+Rake task marks projects where verification has failed or the checksum mismatch
 to be resynced without the back-off period:
 
 For repositories:
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index 606e041c956..ee246381091 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -37,7 +37,7 @@ For information on how to resolve common errors reported from the UI, see
 If the UI is not working, or you are unable to log in, you can run the Geo
 health check manually to get this information as well as a few more details.
 
-This rake task can be run on an app node in the **primary** or **secondary**
+This Rake task can be run on an app node in the **primary** or **secondary**
 Geo nodes:
 
 ```shell
@@ -70,7 +70,7 @@ All projects are in hashed storage? ... yes
 Checking Geo ... Finished
 ```
 
-Current sync information can be found manually by running this rake task on any
+Current sync information can be found manually by running this Rake task on any
 **secondary** app node:
 
 ```shell
@@ -147,9 +147,9 @@ This machine's Geo node name matches a database record ... no
   doc/administration/geo/replication/troubleshooting.md#can-geo-detect-the-current-node-correctly
 ```
 
-## Fixing errors found when running the Geo check rake task
+## Fixing errors found when running the Geo check Rake task
 
-When running this rake task, you may see errors if the nodes are not properly configured:
+When running this Rake task, you may see errors if the nodes are not properly configured:
 
 ```shell
 sudo gitlab-rake gitlab:geo:check
@@ -789,7 +789,7 @@ sudo gitlab-rake geo:db:refresh_foreign_tables
 ## Expired artifacts
 
 If you notice for some reason there are more artifacts on the Geo
-secondary node than on the Geo primary node, you can use the rake task
+secondary node than on the Geo primary node, you can use the Rake task
 to [cleanup orphan artifact files](../../../raketasks/cleanup.md#remove-orphan-artifact-files).
 
 On a Geo **secondary** node, this command will also clean up all Geo
diff --git a/doc/administration/index.md b/doc/administration/index.md
index 2ab4b3f710e..6fefe1a01d0 100644
--- a/doc/administration/index.md
+++ b/doc/administration/index.md
@@ -145,7 +145,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Repository checks](repository_checks.md): Periodic Git repository checks.
 - [Repository storage paths](repository_storage_paths.md): Manage the paths used to store repositories.
 - [Repository storage types](repository_storage_types.md): Information about the different repository storage types.
-- [Repository storage rake tasks](raketasks/storage.md): A collection of rake tasks to list and migrate existing projects and attachments associated with it from Legacy storage to Hashed storage.
+- [Repository storage Rake tasks](raketasks/storage.md): A collection of Rake tasks to list and migrate existing projects and attachments associated with it from Legacy storage to Hashed storage.
 - [Limit repository size](../user/admin_area/settings/account_and_limit_settings.md): Set a hard limit for your repositories' size. **(STARTER ONLY)**
 - [Static objects external storage](static_objects_external_storage.md): Set external storage for static objects in a repository.
 
diff --git a/doc/administration/lfs/lfs_administration.md b/doc/administration/lfs/lfs_administration.md
index d8631b05c14..a7ff624e1c6 100644
--- a/doc/administration/lfs/lfs_administration.md
+++ b/doc/administration/lfs/lfs_administration.md
@@ -136,7 +136,7 @@ and comparing the output of the returned headers.
 
 There are two ways to manually do the same thing as automatic uploading (described above).
 
-**Option 1: rake task**
+**Option 1: Rake task**
 
 ```shell
 rake gitlab:lfs:migrate
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index abf00a5010a..c0edb43cc01 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -20,7 +20,7 @@ to prevent data integrity issues. However, if a Git operation is interrupted the
 locks may not be cleaned up properly.
 
 The following symptoms may indicate a problem with repository integrity. If users
-experience these symptoms you may use the rake tasks described below to determine
+experience these symptoms you may use the Rake tasks described below to determine
 exactly which repositories are causing the trouble.
 
 - Receiving an error when trying to push code - `remote: error: cannot lock ref`
diff --git a/doc/administration/raketasks/geo.md b/doc/administration/raketasks/geo.md
index 91c83b5f6ba..707ed1dbee0 100644
--- a/doc/administration/raketasks/geo.md
+++ b/doc/administration/raketasks/geo.md
@@ -59,7 +59,7 @@ sudo -u git -H bundle exec rake geo:git:housekeeping:gc RAILS_ENV=production
 ## Remove orphaned project registries
 
 Under certain conditions your project registry can contain obsolete records, you
-can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`:
+can remove them using the Rake task `geo:run_orphaned_project_registry_cleaner`:
 
 **Omnibus Installation**
 
diff --git a/doc/administration/raketasks/github_import.md b/doc/administration/raketasks/github_import.md
index 64ab56a57d4..4c6521f38ec 100644
--- a/doc/administration/raketasks/github_import.md
+++ b/doc/administration/raketasks/github_import.md
@@ -4,7 +4,7 @@
 
 In order to retrieve and import GitHub repositories, you will need a
 [GitHub personal access token](https://github.com/settings/tokens).
-A username should be passed as the second argument to the rake task
+A username should be passed as the second argument to the Rake task
 which will become the owner of the project. You can resume an import
 with the same command.
 
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index 6fd6c5dd8c1..c79a1aa6ba1 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -50,7 +50,7 @@ Git:              /usr/bin/git
 
 ## Check GitLab configuration
 
-Runs the following rake tasks:
+Runs the following Rake tasks:
 
 - `gitlab:gitlab_shell:check`
 - `gitlab:gitaly:check`
@@ -209,7 +209,7 @@ sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production
 ## Check TCP connectivity to a remote site
 
 Sometimes you need to know if your GitLab installation can connect to a TCP
-service on another machine - perhaps a PostgreSQL or HTTPS server. A rake task
+service on another machine - perhaps a PostgreSQL or HTTPS server. A Rake task
 is included to help you with this:
 
 **Omnibus Installation**
@@ -258,7 +258,7 @@ sudo gitlab-rake gitlab:exclusive_lease:clear[project_housekeeping:4]
 See the [upgrade documentation](../../update/README.md#checking-for-background-migrations-before-upgrading)
 for how to check that migrations are complete when upgrading GitLab.
 
-To check the status of specific migrations, you can use the following rake task:
+To check the status of specific migrations, you can use the following Rake task:
 
 ```shell
 sudo gitlab-rake db:migrate:status
diff --git a/doc/administration/raketasks/storage.md b/doc/administration/raketasks/storage.md
index a14c8ed7969..1e487a317c9 100644
--- a/doc/administration/raketasks/storage.md
+++ b/doc/administration/raketasks/storage.md
@@ -1,6 +1,6 @@
 # Repository Storage Rake Tasks
 
-This is a collection of rake tasks you can use to help you list and migrate
+This is a collection of Rake tasks you can use to help you list and migrate
 existing projects and attachments associated with it from Legacy storage to
 the new Hashed storage type.
 
@@ -46,7 +46,7 @@ Any error or warning will be logged in Sidekiq's log file.
 NOTE: **Note:**
 If Geo is enabled, each project that is successfully migrated generates an event to replicate the changes on any **secondary** nodes.
 
-You only need the `gitlab:storage:migrate_to_hashed` rake task to migrate your repositories, but we have additional
+You only need the `gitlab:storage:migrate_to_hashed` Rake task to migrate your repositories, but we have additional
 commands below that helps you inspect projects and attachments in both legacy and hashed storage.
 
 ## Rollback from Hashed storage to Legacy storage
diff --git a/doc/administration/raketasks/uploads/migrate.md b/doc/administration/raketasks/uploads/migrate.md
index 2dc07bc09d6..6dae9b71e1f 100644
--- a/doc/administration/raketasks/uploads/migrate.md
+++ b/doc/administration/raketasks/uploads/migrate.md
@@ -7,12 +7,12 @@ After [configuring the object storage](../../uploads.md#using-object-storage-cor
 >**Note:**
 All of the processing will be done in a background worker and requires **no downtime**.
 
-### All-in-one rake task
+### All-in-one Rake task
 
-GitLab provides a wrapper rake task that migrates all uploaded files - avatars,
+GitLab provides a wrapper Rake task that migrates all uploaded files - avatars,
 logos, attachments, favicon, etc. - to object storage in one go. Under the hood,
-it invokes individual rake tasks to migrate files falling under each of this
-category one by one. The specifications of these individual rake tasks are
+it invokes individual Rake tasks to migrate files falling under each of this
+category one by one. The specifications of these individual Rake tasks are
 described in the next section.
 
 **Omnibus Installation**
@@ -27,12 +27,12 @@ gitlab-rake "gitlab:uploads:migrate:all"
 sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:migrate:all
 ```
 
-### Individual rake tasks
+### Individual Rake tasks
 
 >**Note:**
-If you already ran the rake task mentioned above, no need to run these individual rake tasks as that has been done automatically.
+If you already ran the Rake task mentioned above, no need to run these individual Rake tasks as that has been done automatically.
 
-The rake task uses 3 parameters to find uploads to migrate.
+The Rake task uses 3 parameters to find uploads to migrate.
 
 Parameter | Type | Description
 --------- | ---- | -----------
@@ -140,12 +140,12 @@ the migration. A configuration setting will be added soon to allow migrating
 from object storage to local files with only a brief moment of downtime for configuration changes.
 To follow progress, see the [relevant issue](https://gitlab.com/gitlab-org/gitlab/issues/30979).
 
-### All-in-one rake task
+### All-in-one Rake task
 
-GitLab provides a wrapper rake task that migrates all uploaded files - avatars,
+GitLab provides a wrapper Rake task that migrates all uploaded files - avatars,
 logos, attachments, favicon, etc. - to local storage in one go. Under the hood,
-it invokes individual rake tasks to migrate files falling under each of this
-category one by one. For details on these rake tasks please [refer to the section above](#individual-rake-tasks),
+it invokes individual Rake tasks to migrate files falling under each of this
+category one by one. For details on these Rake tasks please [refer to the section above](#individual-rake-tasks),
 keeping in mind the task name in this case is `gitlab:uploads:migrate_to_local`.
 
 **Omnibus Installation**
diff --git a/doc/administration/raketasks/uploads/sanitize.md b/doc/administration/raketasks/uploads/sanitize.md
index 3e9b44a24fb..c00399a27cf 100644
--- a/doc/administration/raketasks/uploads/sanitize.md
+++ b/doc/administration/raketasks/uploads/sanitize.md
@@ -29,7 +29,7 @@ sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:rem
 This command by default runs in dry mode and it doesn't remove EXIF data. It can be used for
 checking if (and how many) images should be sanitized.
 
-The rake task accepts following parameters.
+The Rake task accepts following parameters.
 
 Parameter | Type | Description
 --------- | ---- | -----------
@@ -41,7 +41,7 @@ Parameter | Type | Description
 `since` | date | Run sanitization only for uploads newer than given date (e.g. `2019-05-01`)
 
 If you have too many uploads, you can speed up sanitization by setting
-`sleep_time` to a lower value or by running multiple rake tasks in parallel,
+`sleep_time` to a lower value or by running multiple Rake tasks in parallel,
 each with a separate range of upload IDs (by setting `start_id` and `stop_id`).
 
 To run the command without dry mode and remove EXIF data from all uploads, you can use:
@@ -58,7 +58,7 @@ sudo RAILS_ENV=production -u git -H bundle exec rake gitlab:uploads:sanitize:rem
 
 Because the output of commands will be probably long, the output is written also into exif.log file.
 
-If sanitization fails for an upload, an error message should be in the output of the rake task (typical reasons may
+If sanitization fails for an upload, an error message should be in the output of the Rake task (typical reasons may
 be that the file is missing in the storage or it's not a valid image). Please
 [report](https://gitlab.com/gitlab-org/gitlab-foss/issues/new) any issues at `gitlab.com` and use
 prefix 'EXIF' in issue title with the error output and (if possible) the image.
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index ba0d511b718..f92106a69ca 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -162,7 +162,7 @@ either runs on the same machine as your repositories are located, or may login t
 to access data (for example, a remote backup solution).
 
 To schedule a complete rollout, see the
-[rake task documentation for storage migration][rake/migrate-to-hashed] for instructions.
+[Rake task documentation for storage migration][rake/migrate-to-hashed] for instructions.
 
 If you do have any existing integration, you may want to do a small rollout first,
 to validate. You can do so by specifying a range with the operation.
@@ -186,7 +186,7 @@ projects:
 1. Uncheck the **Use hashed storage paths for newly created and renamed projects** checkbox.
 
 To schedule a complete rollback, see the
-[rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.
+[Rake task documentation for storage rollback](raketasks/storage.md#rollback-from-hashed-storage-to-legacy-storage) for instructions.
 
 The rollback task also supports specifying a range of Project IDs. Here is an example
 of limiting the rollout to Project IDs 50 to 100, in an Omnibus GitLab installation:
diff --git a/doc/administration/timezone.md b/doc/administration/timezone.md
index bc6eaf57a23..fa0fbb43433 100644
--- a/doc/administration/timezone.md
+++ b/doc/administration/timezone.md
@@ -15,7 +15,7 @@ To see all available time zones, run `bundle exec rake time:zones:all`.
 For Omnibus installations, run `gitlab-rake time:zones:all`.
 
 NOTE: **Note:**
-Currently, this rake task does not list timezones in TZInfo format required by GitLab Omnibus during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672).
+Currently, this Rake task does not list timezones in TZInfo format required by GitLab Omnibus during a reconfigure: [#58672](https://gitlab.com/gitlab-org/gitlab-foss/issues/58672).
 
 ## Changing time zone in Omnibus installations
 
diff --git a/doc/administration/troubleshooting/elasticsearch.md b/doc/administration/troubleshooting/elasticsearch.md
index c864fc7b2b6..77a63112ea3 100644
--- a/doc/administration/troubleshooting/elasticsearch.md
+++ b/doc/administration/troubleshooting/elasticsearch.md
@@ -204,7 +204,7 @@ If it is, check on the Elasticsearch side to determine if the `gitlab-production
 name for the GitLab index) exists. If it exists, manually delete it on the Elasticsearch
 side and attempt to recreate it from the
 [`create_empty_index`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks)
-rake task.
+Rake task.
 
 If you still encounter issues, try creating an index manually on the Elasticsearch
 instance. The details of the index aren't important here, as we want to test if indices
@@ -220,7 +220,7 @@ during the indexing of projects. If errors do occur, they will either stem from
   something you are familiar with, contact GitLab support for guidance.
 - Within the Elasticsearch instance itself. See if the error is [documented and has a fix](../../integration/elasticsearch.md#troubleshooting). If not, speak with your Elasticsearch admin.
 
-If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following rake tasks:
+If the indexing process does not present errors, you will want to check the status of the indexed projects. You can do this via the following Rake tasks:
 
 - [`sudo gitlab-rake gitlab:elastic:index_projects_status`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) (shows the overall status)
 - [`sudo gitlab-rake gitlab:elastic:projects_not_indexed`](../../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks) (shows specific projects that are not indexed)
diff --git a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
index 8b06d6ff530..0a4e65add4f 100644
--- a/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
+++ b/doc/administration/troubleshooting/kubernetes_cheat_sheet.md
@@ -117,7 +117,7 @@ and they will assist you with any issues you are having.
   kubectl get events -w --namespace=gitlab
   ```
 
-- Most of the useful GitLab tools (console, rake tasks, etc) are found in the task-runner
+- Most of the useful GitLab tools (console, Rake tasks, etc) are found in the task-runner
   pod. You may enter it and run commands inside or run them from the outside:
 
   ```shell
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index f53c4e63bcb..45cffb64671 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -116,7 +116,7 @@ _The uploads are stored by default in
    ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
-1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
+1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
 
 **In installations from source:**
 
@@ -139,7 +139,7 @@ _The uploads are stored by default in
    ```
 
 1. Save the file and [restart GitLab][] for the changes to take effect.
-1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
+1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
 
 ### Oracle Cloud S3 connection settings
 
@@ -193,7 +193,7 @@ _The uploads are stored by default in
    ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
-1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
+1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
 
 ---
 
@@ -224,7 +224,7 @@ _The uploads are stored by default in
    ```
 
 1. Save the file and [reconfigure GitLab][] for the changes to take effect.
-1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` rake task](raketasks/uploads/migrate.md).
+1. Migrate any existing local uploads to the object storage using [`gitlab:uploads:migrate` Rake task](raketasks/uploads/migrate.md).
 
 [reconfigure gitlab]: restart_gitlab.md#omnibus-gitlab-reconfigure "How to reconfigure Omnibus GitLab"
 [restart gitlab]: restart_gitlab.md#installations-from-source "How to restart GitLab"