Correcting reference link to standard.

GitLab style advises against reference-style links.

doc/administration/audit_events.md

 # Audit Events **(STARTER)**
 
-GitLab offers a way to view the changes made within the GitLab server for owners and administrators on a [paid plan][ee].
+GitLab offers a way to view the changes made within the GitLab server for owners and administrators on a [paid plan](https://about.gitlab.com/pricing/).
 
 GitLab system administrators can also take advantage of the logs located on the
 filesystem. See [the logs system documentation](logs.md) for more details.
@@ -31,7 +31,7 @@ There are two kinds of events logged:
 ### Group events **(STARTER)**
 
 NOTE: **Note:**
-You need Owner [permissions] to view the group Audit Events page.
+You need Owner [permissions](../user/permissions.md) to view the group Audit Events page.
 
 To view a group's audit events, navigate to **Group > Settings > Audit Events**.
 From there, you can see the following actions:
@@ -40,14 +40,14 @@ From there, you can see the following actions:
 - Group repository size limit changed
 - Group created or deleted
 - Group changed visibility
-- User was added to group and with which [permissions]
+- User was added to group and with which [permissions](../user/permissions.md)
 - User sign-in via [Group SAML](../user/group/saml_sso/index.md)
 - Permissions changes of a user assigned to a group
 - Removed user from group
 - Project added to group and with which visibility level
 - Project removed from group
 - [Project shared with group](../user/project/members/share_project_with_groups.md)
-  and with which [permissions]
+  and with which [permissions](../user/permissions.md)
 - Removal of a previously shared group with a project
 - LFS enabled or disabled
 - Shared runners minutes limit changed
@@ -61,7 +61,7 @@ Group events can also be accessed via the [Group Audit Events API](../api/audit_
 ### Project events **(STARTER)**
 
 NOTE: **Note:**
-You need Maintainer [permissions] or higher to view the project Audit Events page.
+You need Maintainer [permissions](../user/permissions.md) or higher to view the project Audit Events page.
 
 To view a project's audit events, navigate to **Project > Settings > Audit Events**.
 From there, you can see the following actions:
@@ -69,7 +69,7 @@ From there, you can see the following actions:
 - Added or removed deploy keys
 - Project created, deleted, renamed, moved(transferred), changed path
 - Project changed visibility level
-- User was added to project and with which [permissions]
+- User was added to project and with which [permissions](../user/permissions.md)
 - Permission changes of a user assigned to a project
 - User was removed from project
 - Project export was downloaded
@@ -86,7 +86,7 @@ From there, you can see the following actions:
 
 ### Instance events **(PREMIUM ONLY)**
 
-> [Introduced][ee-2336] in [GitLab Premium][ee] 9.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/2336) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.3.
 
 Server-wide audit logging introduces the ability to observe user actions across
 the entire instance of your GitLab server, making it easy to understand who
@@ -157,7 +157,3 @@ the steps bellow.
    ```ruby
    Feature.enable(:repository_push_audit_event)
    ```
-
-[ee-2336]: https://gitlab.com/gitlab-org/gitlab/issues/2336
-[ee]: https://about.gitlab.com/pricing/
-[permissions]: ../user/permissions.md

doc/administration/instance_review.md

 # Instance Review **(CORE ONLY)**
 
-> [Introduced][6995] in [GitLab Core][ee] 11.3.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6995) in [GitLab Core](https://about.gitlab.com/pricing/) 11.3.
 
 If you are running a medium size instance of GitLab Core edition you are qualified for a free Instance Review. You can find the button in the User menu.
 
@@ -11,6 +11,3 @@ When you click the button you will be redirected to a form with prefilled data o
 Once you submit the data to GitLab Inc. you can see the initial report.
 
 Additionally you will be contacted by our team for further review which should help you to improve your usage of GitLab.
-
-[6995]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6995
-[ee]: https://about.gitlab.com/pricing/

doc/administration/raketasks/check.md

@@ -133,5 +133,3 @@ The LDAP check Rake task will test the bind DN and password credentials
 (if configured) and will list a sample of LDAP users. This task is also
 executed as part of the `gitlab:check` task, but can run independently.
 See [LDAP Rake Tasks - LDAP Check](ldap.md#check) for details.
-
-[git-fsck]: https://git-scm.com/docs/git-fsck

doc/administration/raketasks/storage.md

@@ -4,12 +4,12 @@ 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.
 
-You can read more about the storage types [here][storage-types].
+You can read more about the storage types [here](../repository_storage_types.md).
 
 ## Migrate existing projects to Hashed storage
 
 Before migrating your existing projects, you should
-[enable hashed storage][storage-migration] for the new projects as well.
+[enable hashed storage](../repository_storage_types.md#how-to-migrate-to-hashed-storage) for the new projects as well.
 
 This task will schedule all your existing projects and attachments associated with it to be migrated to the
 **Hashed** storage type:
@@ -56,7 +56,7 @@ If you need to rollback the storage migration for any reason, you can follow the
 NOTE: **Note:** Hashed Storage will be required in future version of GitLab.
 
 To prevent new projects from being created in the Hashed storage,
-you need to undo the [enable hashed storage][storage-migration] changes.
+you need to undo the [enable hashed storage](../repository_storage_types.md#how-to-migrate-to-hashed-storage) changes.
 
 This task will schedule all your existing projects and associated attachments to be rolled back to the
 Legacy storage type.
@@ -209,6 +209,3 @@ sudo gitlab-rake gitlab:storage:list_hashed_attachments
 ```shell
 sudo -u git -H bundle exec rake gitlab:storage:list_hashed_attachments RAILS_ENV=production
 ```
-
-[storage-types]: ../repository_storage_types.md
-[storage-migration]: ../repository_storage_types.md#how-to-migrate-to-hashed-storage

doc/administration/reply_by_email_postfix_setup.md

 # Set up Postfix for incoming email
 
 This document will take you through the steps of setting up a basic Postfix mail
-server with IMAP authentication on Ubuntu, to be used with [incoming email].
+server with IMAP authentication on Ubuntu, to be used with [incoming email](incoming_email.md).
 
 The instructions make the assumption that you will be using the email address `incoming@gitlab.example.com`, that is, username `incoming` on host `gitlab.example.com`. Don't forget to change it to your actual host when executing the example code snippets.
 
@@ -333,10 +333,8 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
 
 ## Done
 
-If all the tests were successful, Postfix is all set up and ready to receive email! Continue with the [incoming email] guide to configure GitLab.
+If all the tests were successful, Postfix is all set up and ready to receive email! Continue with the [incoming email](incoming_email.md) guide to configure GitLab.
 
 ---
 
 _This document was adapted from <https://help.ubuntu.com/community/PostfixBasicSetupHowto>, by contributors to the Ubuntu documentation wiki._
-
-[incoming email]: incoming_email.md

doc/administration/repository_checks.md

 # Repository checks
 
-> [Introduced][ce-3232] in GitLab 8.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/3232) in GitLab 8.7.
 
-Git has a built-in mechanism, [`git fsck`][git-fsck], to verify the
+Git has a built-in mechanism, [`git fsck`](https://git-scm.com/docs/git-fsck), to verify the
 integrity of all data committed to a repository. GitLab administrators
 can trigger such a check for a project via the project page under the
 admin panel. The checks run asynchronously so it may take a few minutes
@@ -41,7 +41,3 @@ in `repocheck.log`:
 If the periodic repository check causes false alarms, you can clear all repository check states by
 navigating to **Admin Area > Settings > Repository**
 (`/admin/application_settings/repository`) and clicking **Clear all repository checks**.
-
----
-[ce-3232]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/3232 "Auto git fsck"
-[git-fsck]: https://git-scm.com/docs/git-fsck "git fsck documentation"

doc/administration/repository_storage_paths.md

 # Repository storage paths
 
-> [Introduced][ce-4578] in GitLab 8.10.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4578) in GitLab 8.10.
 
 GitLab allows you to define multiple repository storage paths (sometimes called
 storage shards) to distribute the storage load between several mount points.
@@ -34,7 +34,7 @@ storage2:
 ## Configure GitLab
 
 > **Warning:**
-> In order for [backups] to work correctly, the storage path must **not** be a
+> In order for [backups](../raketasks/backup_restore.md) to work correctly, the storage path must **not** be a
 > mount point and the GitLab user should have correct permissions for the parent
 > directory of the path. In Omnibus GitLab this is taken care of automatically,
 > but for source installations you should be extra careful.
@@ -47,7 +47,7 @@ storage2:
 > `gitlab.yml`.
 >
 > This little detail matters because while restoring a backup, the current
-> contents of  `/home/git/repositories` [are moved to][raketask] `/home/git/repositories.old`,
+> contents of  `/home/git/repositories` [are moved to](https://gitlab.com/gitlab-org/gitlab/blob/033e5423a2594e08a7ebcd2379bd2331f4c39032/lib/backup/repository.rb#L54-56) `/home/git/repositories.old`,
 > so if `/home/git/repositories` is the mount point, then `mv` would be moving
 > things between mount points, and bad things could happen. Ideally,
 > `/home/git` would be the mount point, so then things would be moving within the
@@ -79,10 +79,10 @@ NOTE: **Note:** This example uses NFS. We do not recommend using EFS for storage
          path: /mnt/nfs2/repositories
    ```
 
-1. [Restart GitLab][restart-gitlab] for the changes to take effect.
+1. [Restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 >**Note:**
-The [`gitlab_shell: repos_path` entry][repospath] in `gitlab.yml` will be
+The [`gitlab_shell: repos_path` entry](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/8-9-stable/config/gitlab.yml.example#L457) in `gitlab.yml` will be
 deprecated and replaced by `repositories: storages` in the future, so if you
 are upgrading from a version prior to 8.10, make sure to add the configuration
 as described in the step above. After you make the changes and confirm they are
@@ -114,9 +114,3 @@ Repository storage > Storage nodes for new repositories**.
 
 Beginning with GitLab 8.13.4, multiple paths can be chosen. New repositories
 will be randomly placed on one of the selected paths.
-
-[ce-4578]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/4578
-[restart-gitlab]: restart_gitlab.md#installations-from-source
-[backups]: ../raketasks/backup_restore.md
-[raketask]: https://gitlab.com/gitlab-org/gitlab/blob/033e5423a2594e08a7ebcd2379bd2331f4c39032/lib/backup/repository.rb#L54-56
-[repospath]: https://gitlab.com/gitlab-org/gitlab-foss/-/blob/8-9-stable/config/gitlab.yml.example#L457

doc/administration/repository_storage_types.md

 # Repository Storage Types
 
-> [Introduced][ce-28283] in GitLab 10.0.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/28283) in GitLab 10.0.
 
 Two different storage layouts can be used
 to store the repositories on disk and their characteristics.
@@ -10,7 +10,7 @@ locations that can be:
 
 - Mounted to the local disk
 - Exposed as an NFS shared volume
-- Accessed via [Gitaly] on its own machine.
+- Accessed via [Gitaly](gitaly/index.md) on its own machine.
 
 In GitLab, this is configured in `/etc/gitlab/gitlab.rb` by the `git_data_dirs({})`
 configuration hash. The storage layouts discussed here will apply to any shard
@@ -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](raketasks/storage.md#migrate-existing-projects-to-hashed-storage) 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.
@@ -174,7 +174,7 @@ an Omnibus GitLab installation:
 sudo gitlab-rake gitlab:storage:migrate_to_hashed ID_FROM=50 ID_TO=100
 ```
 
-Check the [documentation][rake/migrate-to-hashed] for additional information and instructions for
+Check the [documentation](raketasks/storage.md#migrate-existing-projects-to-hashed-storage) for additional information and instructions for
 source-based installation.
 
 #### Rollback
@@ -203,7 +203,7 @@ the remaining repositories from the special `@hashed/` folder manually.
 
 We are incrementally moving every storable object in GitLab to the Hashed
 Storage pattern. You can check the current coverage status below (and also see
-the [issue][ce-2821]).
+the [issue](https://gitlab.com/gitlab-com/infrastructure/issues/2821)).
 
 Note that things stored in an S3 compatible endpoint will not have the downsides
 mentioned earlier, if they are not prefixed with `#{namespace}/#{project_name}`,
@@ -246,8 +246,3 @@ storage pattern using 2 chars, 2 level folders, following Git's own implementati
 ```
 
 LFS objects are also [S3 compatible](lfs/index.md#storing-lfs-objects-in-remote-object-storage).
-
-[ce-2821]: https://gitlab.com/gitlab-com/infrastructure/issues/2821
-[ce-28283]: https://gitlab.com/gitlab-org/gitlab-foss/issues/28283
-[rake/migrate-to-hashed]: raketasks/storage.md#migrate-existing-projects-to-hashed-storage
-[gitaly]: gitaly/index.md

doc/administration/restart_gitlab.md

@@ -12,7 +12,7 @@ If you want the TL;DR versions, jump to:
 
 ## Omnibus installations
 
-If you have used the [Omnibus packages][omnibus-dl] to install GitLab, then
+If you have used the [Omnibus packages](https://about.gitlab.com/install/) to install GitLab, then
 you should already have `gitlab-ctl` in your `PATH`.
 
 `gitlab-ctl` interacts with the Omnibus packages and can be used to restart the
@@ -23,7 +23,7 @@ GitLab Rails application (Unicorn) as well as the other components, like:
 - PostgreSQL (if you are using the bundled one)
 - NGINX (if you are using the bundled one)
 - Redis (if you are using the bundled one)
-- [Mailroom][]
+- [Mailroom](reply_by_email.md)
 - Logrotate
 
 ### Omnibus GitLab restart
@@ -86,7 +86,7 @@ sudo gitlab-ctl reconfigure
 Reconfiguring GitLab should occur in the event that something in its
 configuration (`/etc/gitlab/gitlab.rb`) has changed.
 
-When you run this command, [Chef], the underlying configuration management
+When you run this command, [Chef](https://www.chef.io/products/chef-infra/), the underlying configuration management
 application that powers Omnibus GitLab, will make sure that all things like directories,
 permissions, and services are in place and in the same shape that they were
 initially shipped.
@@ -101,7 +101,7 @@ depend on those files.
 ## Installations from source
 
 If you have followed the official installation guide to [install GitLab from
-source][install], run the following command to restart GitLab:
+source](../install/installation.md), run the following command to restart GitLab:
 
 ```shell
 sudo service gitlab restart
@@ -128,23 +128,16 @@ The GitLab MailRoom email processor with pid 28114 is running.
 GitLab and all its components are up and running.
 ```
 
-This should restart Unicorn, Sidekiq, GitLab Workhorse, and [Mailroom][]
+This should restart Unicorn, Sidekiq, GitLab Workhorse, and [Mailroom](reply_by_email.md)
 (if enabled). The init service file that does all the magic can be found on
 your server in `/etc/init.d/gitlab`.
 
 ---
 
 If you are using other init systems, like systemd, you can check the
-[GitLab Recipes][gl-recipes] repository for some unofficial services. These are
+[GitLab Recipes](https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init) repository for some unofficial services. These are
 **not** officially supported so use them at your own risk.
 
-[omnibus-dl]: https://about.gitlab.com/install/ "Download the Omnibus packages"
-[install]: ../install/installation.md "Documentation to install GitLab from source"
-[mailroom]: reply_by_email.md "Used for replying by email in GitLab issues and merge requests"
-[chef]: https://www.chef.io/products/chef-infra/ "Chef official website"
-[src-service]: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/support/init.d/gitlab "GitLab init service file"
-[gl-recipes]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/init "GitLab Recipes repository"
-
 ## Helm chart installations
 
 There is no single command to restart the entire GitLab application installed via

doc/administration/uploads.md

@@ -25,7 +25,7 @@ _The uploads are stored by default in `/var/opt/gitlab/gitlab-rails/uploads`._
    gitlab_rails['uploads_base_dir'] = "uploads"
    ```
 
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 **In installations from source:**
 
@@ -41,13 +41,13 @@ _The uploads are stored by default in
      base_dir: uploads
    ```
 
-1. Save the file and [restart GitLab][] for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 ## Using object storage **(CORE ONLY)**
 
 > **Notes:**
 >
-> - [Introduced][ee-3867] in [GitLab Premium][eep] 10.5.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3867) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.5.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17358) in [GitLab Core](https://about.gitlab.com/pricing/) 10.7.
 > - Since version 11.1, we support direct_upload to S3.
 
@@ -117,7 +117,7 @@ _The uploads are stored by default in
    }
    ```
 
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) 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).
 
 **In installations from source:**
@@ -140,7 +140,7 @@ _The uploads are stored by default in
          region: eu-central-1
    ```
 
-1. Save the file and [restart GitLab][] for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) 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).
 
 ### Oracle Cloud S3 connection settings
@@ -194,7 +194,7 @@ _The uploads are stored by default in
    }
    ```
 
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) 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).
 
 ---
@@ -225,10 +225,5 @@ _The uploads are stored by default in
          openstack_tenant: 'TENANT_ID'
    ```
 
-1. Save the file and [reconfigure GitLab][] for the changes to take effect.
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) 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).
-
-[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"
-[eep]: https://about.gitlab.com/pricing/ "GitLab Premium"
-[ee-3867]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/3867

doc/api/commits.md

@@ -65,7 +65,7 @@ Example response:
 
 ## Create a commit with multiple files and actions
 
-> [Introduced][ce-6096] in GitLab 8.13.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6096) in GitLab 8.13.
 
 Create a commit by posting a JSON payload
 
@@ -245,7 +245,7 @@ Example response:
 
 ## Get references a commit is pushed to
 
-> [Introduced][ce-15026] in GitLab 10.6
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15026) in GitLab 10.6
 
 Get all references (from branches or tags) a commit is pushed to.
 The pagination parameters `page` and `per_page` can be used to restrict the list of references.
@@ -280,7 +280,7 @@ Example response:
 
 ## Cherry pick a commit
 
-> [Introduced][ce-8047] in GitLab 8.15.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8047) in GitLab 8.15.
 
 Cherry picks a commit to a given branch.
 
@@ -340,7 +340,7 @@ conflict.
 
 ## Revert a commit
 
-> [Introduced][ce-22919] in GitLab 11.5.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22919) in GitLab 11.5.
 
 Reverts a commit in a given branch.
 
@@ -653,7 +653,7 @@ Example response:
 
 ## List Merge Requests associated with a commit
 
-> [Introduced][ce-18004] in GitLab 10.7.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18004) in GitLab 10.7.
 
 Get a list of Merge Requests related to the specified commit.
 
@@ -785,9 +785,3 @@ Example response if commit is unsigned:
   "message": "404 GPG Signature Not Found"
 }
 ```
-
-[ce-6096]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/6096 "Multi-file commit"
-[ce-8047]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/8047
-[ce-15026]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/15026
-[ce-18004]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18004
-[ce-22919]: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22919

doc/development/background_migrations.md

@@ -157,7 +157,7 @@ roughly be as follows:
          enough times to be marked as dead.
    1. Remove the old column.
 
-This may also require a bump to the [import/export version][import-export], if
+This may also require a bump to the [import/export version](../user/project/settings/import_export.md), if
 importing a project from a prior version of GitLab requires the data to be in
 the new format.
 
@@ -283,7 +283,7 @@ end
 The final step runs for any un-migrated rows after all of the jobs have been
 processed. This is in case a Sidekiq process running the background migrations
 received SIGKILL, leading to the jobs being lost. (See
-[more reliable Sidekiq queue][reliable-sidekiq] for more information.)
+[more reliable Sidekiq queue](https://gitlab.com/gitlab-org/gitlab-foss/issues/36791) for more information.)
 
 If the application does not depend on the data being 100% migrated (for
 instance, the data is advisory, and not mission-critical), then this final step
@@ -312,7 +312,7 @@ to migrate you database down and up, which can result in other background
 migrations being called. That means that using `spy` test doubles with
 `have_received` is encouraged, instead of using regular test doubles, because
 your expectations defined in a `it` block can conflict with what is being
-called in RSpec hooks. See [issue #35351][issue-rspec-hooks]
+called in RSpec hooks. See [issue #35351](https://gitlab.com/gitlab-org/gitlab/issues/18839)
 for more details.
 
 ## Best practices
@@ -329,8 +329,3 @@ for more details.
 1. Make sure to discuss the numbers with a database specialist, the migration may add
    more pressure on DB than you expect (measure on staging,
    or ask someone to measure on production).
-
-[migrations-readme]: https://gitlab.com/gitlab-org/gitlab/blob/master/spec/migrations/README.md
-[issue-rspec-hooks]: https://gitlab.com/gitlab-org/gitlab/issues/18839
-[reliable-sidekiq]: https://gitlab.com/gitlab-org/gitlab-foss/issues/36791
-[import-export]: ../user/project/settings/import_export.md