Add new entries for Rake tasks table

Also standardizes capitalization of Rake.

.markdownlint.json

@@ -97,6 +97,7 @@
       "Prometheus",
       "Puma",
       "Python",
+      "Rake",
       "Redis",
       "Redmine",
       "reCAPTCHA",

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.

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.
 

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:

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

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.
 

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

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`

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**
 

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.
 

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

doc/administration/raketasks/storage.md

 # 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

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**

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.

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:

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
 

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)

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

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"

doc/api/project_import_export.md

@@ -5,7 +5,7 @@
 See also:
 
 - [Project import/export documentation](../user/project/settings/import_export.md).
-- [Project import/export administration rake tasks](../administration/raketasks/project_import_export.md). **(CORE ONLY)**
+- [Project import/export administration Rake tasks](../administration/raketasks/project_import_export.md). **(CORE ONLY)**
 
 ## Schedule an export
 

doc/development/architecture.md

@@ -725,7 +725,7 @@ GitLab Shell has a configuration file at `/home/git/gitlab-shell/config.yml`.
 
 ### Maintenance Tasks
 
-[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance rake tasks](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/raketasks/maintenance.md).
+[GitLab](https://gitlab.com/gitlab-org/gitlab/tree/master) provides Rake tasks with which you see version information and run a quick check on your configuration to ensure it is configured properly within the application. See [maintenance Rake tasks](../raketasks/maintenance.md).
 In a nutshell, do the following:
 
 ```shell

doc/development/dangerbot.md

@@ -31,7 +31,7 @@ from the start of the merge request.
 
 ## Run Danger locally
 
-A subset of the current checks can be run locally with the following rake task:
+A subset of the current checks can be run locally with the following Rake task:
 
 ```shell
 bin/rake danger_local

doc/development/elasticsearch.md

@@ -25,7 +25,7 @@ Developers making significant changes to Elasticsearch queries should test their
 
 See the [Elasticsearch GDK setup instructions](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/master/doc/howto/elasticsearch.md)
 
-## Helpful rake tasks
+## Helpful Rake tasks
 
 - `gitlab:elastic:test:index_size`: Tells you how much space the current index is using, as well as how many documents are in the index.
 - `gitlab:elastic:test:index_size_change`: Outputs index size, reindexes, and outputs index size again. Useful when testing improvements to indexing size.
@@ -34,7 +34,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons
 
 ## How does it work?
 
-The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
+The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a Rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
 
 After initial indexing is complete, create, update, and delete operations for all models except projects (see [#207494](https://gitlab.com/gitlab-org/gitlab/issues/207494)) are tracked in a Redis [`ZSET`](https://redis.io/topics/data-types#sorted-sets). A regular `sidekiq-cron` `ElasticIndexBulkCronWorker` processes this queue, updating many Elasticsearch documents at a time with the [Bulk Request API](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html).
 

doc/development/file_storage.md

@@ -50,9 +50,9 @@ In the case of Issues/MR/Notes Markdown attachments, there is a different approa
 instead of basing the path into a mutable variable `:project_path_with_namespace`, it's possible to use the
 hash of the project ID instead, if project migrates to the new approach (introduced in 10.2).
 
-> Note: We provide an [all-in-one rake task] to migrate all uploads to object
+> Note: We provide an [all-in-one Rake task] to migrate all uploads to object
 > storage in one go. If a new Uploader class or model type is introduced, make
-> sure you add a rake task invocation corresponding to it to the [category
+> sure you add a Rake task invocation corresponding to it to the [category
 > list].
 
 ### Path segments

doc/development/import_project.md

@@ -45,7 +45,7 @@ There is also an option to [import the project via GitHub](../user/project/impor
 
 This method will take longer to import than the other methods and will depend on several factors. It's recommended to use the other methods.
 
-### Importing via a rake task
+### Importing via a Rake task
 
 [`import.rake`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/tasks/gitlab/import_export/import.rake) was introduced for importing large GitLab project exports.
 

doc/development/rake_tasks.md

@@ -129,11 +129,11 @@ To run several tests inside one directory:
 
 - `bin/rspec spec/requests/api/` for the rspec tests if you want to test API only
 
-### Speed-up tests, rake tasks, and migrations
+### Speed-up tests, Rake tasks, and migrations
 
 [Spring](https://github.com/rails/spring) is a Rails application preloader. It
 speeds up development by keeping your application running in the background so
-you don't need to boot it every time you run a test, rake task or migration.
+you don't need to boot it every time you run a test, Rake task or migration.
 
 If you want to use it, you'll need to export the `ENABLE_SPRING` environment
 variable to `1`:
@@ -247,7 +247,7 @@ To generate GraphQL documentation based on the GitLab schema, run:
 bundle exec rake gitlab:graphql:compile_docs
 ```
 
-In its current state, the rake task:
+In its current state, the Rake task:
 
 - Generates output for GraphQL objects.
 - Places the output at `doc/api/graphql/reference/index.md`.
@@ -270,4 +270,4 @@ To generate GraphQL schema files based on the GitLab schema, run:
 bundle exec rake gitlab:graphql:schema:dump
 ```
 
-This uses graphql-ruby's built-in rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats.
+This uses graphql-ruby's built-in Rake tasks to generate files in both [IDL](https://www.prisma.io/blog/graphql-sdl-schema-definition-language-6755bcb9ce51) and JSON formats.

doc/integration/elasticsearch.md

@@ -141,7 +141,7 @@ The following Elasticsearch settings are available:
 
 | Parameter                                             | Description |
 | ----------------------------------------------------- | ----------- |
-| `Elasticsearch indexing`                              | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
+| `Elasticsearch indexing`                              | Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also, keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special Rake task for that as explained in [Adding GitLab's data to the Elasticsearch index](#adding-gitlabs-data-to-the-elasticsearch-index). |
 | `Search with Elasticsearch enabled`                   | Enables/disables using Elasticsearch in search. |
 | `URL`                                                 | The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., `http://host1, https://host2:9200`). If your Elasticsearch instance is password protected, pass the `username:password` in the URL (e.g., `http://<username>:<password>@<elastic_host>:9200/`). |
 | `Number of Elasticsearch shards`                      | Elasticsearch indexes are split into multiple shards for performance reasons. In general, larger indexes need to have more shards. Changes to this value do not take effect until the index is recreated. You can read more about tradeoffs in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-create-index.html#create-index-settings) |
@@ -174,7 +174,7 @@ If no namespaces or projects are selected, no Elasticsearch indexing will take p
 
 CAUTION: **Warning**:
 If you have already indexed your instance, you will have to regenerate the index in order to delete all existing data
-for filtering to work correctly. To do this run the rake tasks `gitlab:elastic:create_empty_index` and
+for filtering to work correctly. To do this run the Rake tasks `gitlab:elastic:create_empty_index` and
 `gitlab:elastic:clear_index_status`. Afterwards, removing a namespace or a project from the list will delete the data
 from the Elasticsearch index as expected.
 
@@ -298,7 +298,7 @@ or creating [extra Sidekiq processes](../administration/operations/extra_sidekiq
 
    This enqueues a Sidekiq job for each project that needs to be indexed.
    You can view the jobs in **Admin Area > Monitoring > Background Jobs > Queues Tab**
-   and click `elastic_indexer`, or you can query indexing status using a rake task:
+   and click `elastic_indexer`, or you can query indexing status using a Rake task:
 
    ```shell
    # Omnibus installations
@@ -402,7 +402,7 @@ For repository and snippet files, GitLab will only index up to 1 MiB of content,
 
 ## GitLab Elasticsearch Rake Tasks
 
-There are several rake tasks available to you via the command line:
+There are several Rake tasks available to you via the command line:
 
 - [`sudo gitlab-rake gitlab:elastic:index`](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/lib/tasks/gitlab/elastic.rake)
   - This is a wrapper task. It does the following:
@@ -438,7 +438,7 @@ There are several rake tasks available to you via the command line:
 
 ### Environment Variables
 
-In addition to the rake tasks, there are some environment variables that can be used to modify the process:
+In addition to the Rake tasks, there are some environment variables that can be used to modify the process:
 
 | Environment Variable | Data Type | What it does                                                                 |
 | -------------------- |:---------:| ---------------------------------------------------------------------------- |
@@ -550,7 +550,7 @@ Here are some common pitfalls and how to overcome them:
 
 - **I indexed all the repositories but then switched Elasticsearch servers and now I can't find anything**
 
-  You will need to re-run all the rake tasks to re-index the database, repositories, and wikis.
+  You will need to re-run all the Rake tasks to re-index the database, repositories, and wikis.
 
 - **The indexing process is taking a very long time**
 
@@ -564,7 +564,7 @@ Here are some common pitfalls and how to overcome them:
 
   When performing the initial indexing of blobs, we lock all projects until the project finishes indexing. It could
   happen that an error during the process causes one or multiple projects to remain locked. In order to unlock them,
-  run the `gitlab:elastic:clear_locked_projects` rake task.
+  run the `gitlab:elastic:clear_locked_projects` Rake task.
 
 - **"Can't specify parent if no parent field has been configured"**
 
@@ -632,7 +632,7 @@ Here are some common pitfalls and how to overcome them:
    ```
 
    You probably have not used either `http://` or `https://` as part of your value in the **"URL"** field of the Elasticseach Integration Menu. Please make sure you are using either `http://` or `https://` in this field as the [Elasticsearch client for Go](https://github.com/olivere/elastic) that we are using [needs the prefix for the URL to be accepted as valid](https://github.com/olivere/elastic/commit/a80af35aa41856dc2c986204e2b64eab81ccac3a).
-   Once you have corrected the formatting of the URL, delete the index (via the [dedicated rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index).
+   Once you have corrected the formatting of the URL, delete the index (via the [dedicated Rake task](#gitlab-elasticsearch-rake-tasks)) and [reindex the content of your instance](#adding-gitlabs-data-to-the-elasticsearch-index).
 
 ### Reverting to basic search
 

doc/migrate_ci_to_ce/README.md

@@ -131,8 +131,8 @@ First upgrade your GitLab server to version 8.0:
 
 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)**.
+**Continuous Integration** uncheck **Disable to prevent CI usage until `rake
+ci:migrate` is run (8.0 only)**.
 
 ### 3. CI settings are now in GitLab
 
@@ -184,7 +184,7 @@ sudo -u gitlab_ci -H bundle exec rake backup:show_secrets RAILS_ENV=production
 ### 2. SQL data and build traces
 
 Create your final CI data export. If you are converting from MySQL to
-PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When
+PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the Rake command. When
 the command finishes it will print the path to your data export archive; you
 will need this file later.
 

doc/raketasks/README.md

@@ -19,6 +19,8 @@ The following are available Rake tasks:
 |:-------------------------------------------------------------------------------------------|:------------------------------------------------------------------------------------------|
 | [Back up and restore](backup_restore.md)                                                   | Back up, restore, and migrate GitLab instances between servers.                           |
 | [Clean up](cleanup.md)                                                                     | Clean up unneeded items GitLab instances.                                                 |
+| [Development](../development/rake_tasks.md)                                                | Tasks for GitLab contributors.                                                            |
+| [Elasticsearch](../integration/elasticsearch.md#gitlab-elasticsearch-rake-tasks)           | Maintain Elasticsearch in a GitLab instance.                                              |
 | [Enable namespaces](features.md)                                                           | Enable usernames and namespaces for user projects.                                        |
 | [General maintenance](../administration/raketasks/maintenance.md)                          | General maintenance and self-check tasks.                                                 |
 | [Geo maintenance](../administration/raketasks/geo.md) **(PREMIUM ONLY)**                   | [Geo](../administration/geo/replication/index.md)-related maintenance.                    |

doc/raketasks/backup_restore.md

@@ -109,7 +109,7 @@ kubectl exec -it <gitlab task-runner pod> backup-utility
 Similarly to the Kubernetes case, if you have scaled out your GitLab
 cluster to use multiple application servers, you should pick a
 designated node (that won't be auto-scaled away) for running the
-backup rake task. Because the backup rake task is tightly coupled to
+backup Rake task. Because the backup Rake task is tightly coupled to
 the main Rails application, this is typically a node on which you're
 also running Unicorn/Puma and/or Sidekiq.
 
@@ -171,7 +171,7 @@ the GitLab container according to the documentation, it should be under
 `/srv/gitlab/config`.
 
 For [GitLab Helm chart Installations](https://gitlab.com/gitlab-org/charts/gitlab) on a
-Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions.  
+Kubernetes cluster, you must follow the [Backup the secrets](https://docs.gitlab.com/charts/backup-restore/backup.html#backup-the-secrets) instructions.
 
 You may also want to back up any TLS keys and certificates, and your
 [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079).
@@ -819,7 +819,7 @@ a Kubernetes cluster, the restore task expects the restore directories to be emp
 However, with docker and Kubernetes volume mounts, some system level directories
 may be created at the volume roots, like `lost+found` directory found in Linux
 operating systems. These directories are usually owned by `root`, which can
-cause access permission errors since the restore rake task runs as `git` user.
+cause access permission errors since the restore Rake task runs as `git` user.
 So, to restore a GitLab installation, users have to confirm the restore target
 directories are empty.
 
@@ -875,8 +875,8 @@ to export / backup your data yourself from GitLab.com.
 Issues are stored in the database. They can't be stored in Git itself.
 
 To migrate your repositories from one server to another with an up-to-date version of
-GitLab, you can use the [import rake task](import.md) to do a mass import of the
-repository. Note that if you do an import rake task, rather than a backup restore, you
+GitLab, you can use the [import Rake task](import.md) to do a mass import of the
+repository. Note that if you do an import Rake task, rather than a backup restore, you
 will have all your repositories, but not any other data.
 
 ## Troubleshooting
@@ -893,7 +893,7 @@ psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING:  no privileges were
 
 Be advised that, backup is successfully restored in spite of these warnings.
 
-The rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
+The Rake task runs this as the `gitlab` user which does not have the superuser access to the database. When restore is initiated it will also run as `gitlab` user but it will also try to alter the objects it does not have access to.
 Those objects have no influence on the database backup/restore but they give this annoying warning.
 
 For more information see similar questions on PostgreSQL issue tracker[here](https://www.postgresql.org/message-id/201110220712.30886.adrian.klaver@gmail.com) and [here](https://www.postgresql.org/message-id/2039.1177339749@sss.pgh.pa.us) as well as [stack overflow](https://stackoverflow.com/questions/4368789/error-must-be-owner-of-language-plpgsql).

doc/raketasks/cleanup.md

@@ -9,7 +9,7 @@ GitLab provides Rake tasks for cleaning up GitLab instances.
 DANGER: **Danger:**
 Do not run this within 12 hours of a GitLab upgrade. This is to ensure that all background migrations have finished, which otherwise may lead to data loss.
 
-When you remove LFS files from a repository's history, they become orphaned and continue to consume disk space. With this rake task, you can remove invalid references from the database, which
+When you remove LFS files from a repository's history, they become orphaned and continue to consume disk space. With this Rake task, you can remove invalid references from the database, which
 will allow garbage collection of LFS files.
 
 For example:
@@ -36,7 +36,7 @@ By default, this task does not delete anything but shows how many file reference
 delete. Run the command with `DRY_RUN=false` if you actually want to
 delete the references. You can also use `LIMIT={number}` parameter to limit the number of deleted references.
 
-Note that this rake task only removes the references to LFS files. Unreferenced LFS files will be garbage-collected
+Note that this Rake task only removes the references to LFS files. Unreferenced LFS files will be garbage-collected
 later (once a day). If you need to garbage collect them immediately, run
 `rake gitlab:cleanup:orphan_lfs_files` described below.
 

doc/security/two_factor_authentication.md

@@ -65,7 +65,7 @@ The following are important notes about 2FA:
 ## Disabling 2FA for everyone
 
 There may be some special situations where you want to disable 2FA for everyone
-even when forced 2FA is disabled. There is a rake task for that:
+even when forced 2FA is disabled. There is a Rake task for that:
 
 ```shell
 # Omnibus installations

doc/university/support/README.md

@@ -62,14 +62,14 @@ Sometimes we need to upgrade customers from old versions of GitLab to latest, so
     - Users
     - Groups
     - Projects
-  - [Backup using our Backup rake task](../../raketasks/backup_restore.md#creating-a-backup-of-the-gitlab-system)
+  - [Backup using our Backup Rake task](../../raketasks/backup_restore.md#creating-a-backup-of-the-gitlab-system)
   - [Upgrade to 5.0 source using our Upgrade documentation](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/4.2-to-5.0.md)
   - [Upgrade to 5.1 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/5.0-to-5.1.md)
   - [Upgrade to 6.0 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/5.1-to-6.0.md)
   - [Upgrade to 7.14 source](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/6.x-or-7.x-to-7.14.md)
   - [Perform the MySQL to PostgreSQL migration to convert your backup](../../update/mysql_to_postgresql.md)
   - [Upgrade to Omnibus 7.14](https://docs.gitlab.com/omnibus/update/README.html#upgrading-from-a-non-omnibus-installation-to-an-omnibus-installation)
-  - [Restore backup using our Restore rake task](../../raketasks/backup_restore.md#restore)
+  - [Restore backup using our Restore Rake task](../../raketasks/backup_restore.md#restore)
   - [Upgrade to latest EE](https://about.gitlab.com/update/)
     - (GitLab inc. only) Acquire and apply a license for the Enterprise Edition product, ask in #support
 - Perform a downgrade from [EE to CE](../../downgrade_ee_to_ce/README.md)

doc/update/README.md

@@ -147,7 +147,7 @@ puts Sidekiq::Queue.new("background_migration").size
 Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
 ```
 
-There is also a [rake task](../administration/raketasks/maintenance.md#display-status-of-database-migrations)
+There is also a [Rake task](../administration/raketasks/maintenance.md#display-status-of-database-migrations)
 for displaying the status of each database migration.
 
 ## Upgrading to a new major version

doc/update/restore_after_failure.md

@@ -45,7 +45,7 @@ need to do.
 
 ### GitLab 8.6+
 
-Pass the version to a database rake task to manually mark the migration as
+Pass the version to a database Rake task to manually mark the migration as
 complete.
 
 ```shell
@@ -56,7 +56,7 @@ sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857
 sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
 ```
 
-Once the migration is successfully marked, run the rake `db:migrate` task again.
+Once the migration is successfully marked, run the Rake `db:migrate` task again.
 You will likely have to repeat this process several times until all failed
 migrations are marked complete.
 
@@ -77,6 +77,6 @@ ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) V
 exit
 ```
 
-Once the migration is successfully marked, run the rake `db:migrate` task again.
+Once the migration is successfully marked, run the Rake `db:migrate` task again.
 You will likely have to repeat this process several times until all failed
 migrations are marked complete.

doc/user/project/import/github.md

@@ -14,7 +14,7 @@ GitHub repositories using a [personal access token](#using-a-github-token),
 but this method is not recommended because it cannot associate all user activity
 (such as issues and pull requests) with matching GitLab users.
 If you are an administrator of a self-managed GitLab instance, you can also use the
-[GitHub rake task](../../../administration/raketasks/github_import.md) to import projects from
+[GitHub Rake task](../../../administration/raketasks/github_import.md) to import projects from
 GitHub without the constraints of a Sidekiq worker.
 
 The following aspects of a project are imported:

doc/user/project/integrations/prometheus.md

@@ -878,7 +878,7 @@ If the "No data found" screen continues to appear, it could be due to:
   are not labeled correctly. To test this, connect to the Prometheus server and
   [run a query](prometheus_library/kubernetes.md#metrics-supported), replacing `$CI_ENVIRONMENT_SLUG`
   with the name of your environment.
-- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics rake task](../../../administration/raketasks/maintenance.md#import-common-metrics).
+- You may need to re-add the GitLab predefined common metrics. This can be done by running the [import common metrics Rake task](../../../administration/raketasks/maintenance.md#import-common-metrics).
 
 [autodeploy]: ../../../topics/autodevops/index.md#auto-deploy
 [kubernetes]: https://kubernetes.io

doc/user/project/settings/import_export.md

@@ -11,7 +11,7 @@ The **GitLab import/export** button is displayed if the project import option is
 See also:
 
 - [Project import/export API](../../../api/project_import_export.md)
-- [Project import/export administration rake tasks](../../../administration/raketasks/project_import_export.md) **(CORE ONLY)**
+- [Project import/export administration Rake tasks](../../../administration/raketasks/project_import_export.md) **(CORE ONLY)**
 - [Group import/export API](../../../api/group_import_export.md)
 
 To set up a project import/export: