Update outbound links, move image

Move the one image included in these pages into a subdir with the
rest of these files. Fix the outbound links from these pages to
include the new directory traversal.

doc/user/project/repository/mirror/bidirectional.md

@@ -18,29 +18,29 @@ bidirectional mirroring, you should prepare for the likely conflicts by deciding
 them and how.
 
 Rewriting any mirrored commit on either remote causes conflicts and mirroring to fail. This can
-be prevented by [mirroring only protected branches](#mirror-only-protected-branches).
+be prevented by [mirroring only protected branches](index.md#mirror-only-protected-branches).
 
-You should [protect the branches](../protected_branches.md) you wish to mirror on both
+You should [protect the branches](../../protected_branches.md) you wish to mirror on both
 remotes to prevent conflicts caused by rewriting history.
 
 Bidirectional mirroring also creates a race condition where commits made close together to the same
 branch causes conflicts. The race condition can be mitigated by reducing the mirroring delay by using
-a [Push event webhook](../integrations/webhooks.md#push-events) to trigger an immediate
+a [Push event webhook](../../integrations/webhooks.md#push-events) to trigger an immediate
 pull to GitLab. Push mirroring from GitLab is rate limited to once per minute when only push mirroring
 protected branches.
 
 ## Configure a webhook to trigger an immediate pull to GitLab
 
-Assuming you have already configured the [push](#set-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated)
-and [pull](#pull-from-a-remote-repository) mirrors in the upstream GitLab instance, to trigger an
-immediate pull as suggested above, you must configure a [Push Event Web Hook](../integrations/webhooks.md#push-events)
+Assuming you have already configured the [push](push.md#set-up-a-push-mirror-to-another-gitlab-instance-with-2fa-activated)
+and [pull](pull.md#pull-from-a-remote-repository) mirrors in the upstream GitLab instance, to trigger an
+immediate pull as suggested above, you must configure a [Push Event Web Hook](../../integrations/webhooks.md#push-events)
 in the downstream instance.
 
 To do this:
 
-1. Create a [personal access token](../../profile/personal_access_tokens.md) with `API` scope.
+1. Create a [personal access token](../../../profile/personal_access_tokens.md) with `API` scope.
 1. In your project, go to **Settings > Webhooks**.
-1. Add the webhook URL which (in this case) uses the [Pull Mirror API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project)
+1. Add the webhook URL which (in this case) uses the [Pull Mirror API](../../../../api/projects.md#start-the-pull-mirroring-process-for-a-project)
    request to trigger an immediate pull after updates to the repository.
 
    ```plaintext
@@ -65,7 +65,7 @@ the upstream Git repository. In this configuration one Git repository acts as
 the authoritative upstream, and the other as downstream. The `pre-receive` hook
 is installed on the downstream repository.
 
-Read about [configuring Server hooks](../../../administration/server_hooks.md) on the GitLab server.
+Read about [configuring Server hooks](../../../../administration/server_hooks.md) on the GitLab server.
 
 A sample `pre-receive` hook is provided below.
 

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

@@ -14,25 +14,25 @@ a repository outside of GitLab.
 A repository mirror at GitLab updates automatically. You can also manually trigger an update:
 
 - At most once every five minutes on GitLab.com.
-- According to a [limit set by the administrator](../../../administration/instance_limits.md#pull-mirroring-interval)
+- According to a [limit set by the administrator](../../../../administration/instance_limits.md#pull-mirroring-interval)
   on self-managed instances.
 
 There are two kinds of repository mirroring supported by GitLab:
 
-- [Push](#push-to-a-remote-repository): for mirroring a GitLab repository to another location.
-- [Pull](#pull-from-a-remote-repository): for mirroring a repository from another location to GitLab.
+- [Push](push.md): for mirroring a GitLab repository to another location.
+- [Pull](pull.md): for mirroring a repository from another location to GitLab.
 
 When the mirror repository is updated, all new branches, tags, and commits are visible in the
 project's activity feed.
 
-Users with the [Maintainer role](../../permissions.md) for the project can also force an
+Users with the [Maintainer role](../../../permissions.md) for the project can also force an
 immediate update, unless:
 
 - The mirror is already being updated.
-- The [limit for pull mirroring interval seconds](../../../administration/instance_limits.md#pull-mirroring-interval) has not elapsed after its last update.
+- The [limit for pull mirroring interval seconds](../../../../administration/instance_limits.md#pull-mirroring-interval) has not elapsed after its last update.
 
 For security reasons, the URL to the original repository is only displayed to users with the
-[Maintainer role](../../permissions.md) or the [Owner role](../../permissions.md) for the mirrored
+[Maintainer role](../../../permissions.md) or the [Owner role](../../../permissions.md) for the mirrored
 project.
 
 ## Use cases
@@ -56,7 +56,7 @@ The following are some possible use cases for repository mirroring:
 > Moved to GitLab Premium in 13.9.
 
 Based on the mirror direction that you choose, you can opt to mirror only the
-[protected branches](../protected_branches.md) in the mirroring project,
+[protected branches](../../protected_branches.md) in the mirroring project,
 either from or to your remote repository. For pull mirroring, non-protected branches in
 the mirroring project are not mirrored and can diverge.
 
@@ -80,7 +80,7 @@ If you're mirroring over SSH (using an `ssh://` URL), you can authenticate using
 
 - Password-based authentication, just as over HTTPS.
 - Public key authentication. This is often more secure than password authentication,
-  especially when the other repository supports [deploy keys](../deploy_keys/index.md).
+  especially when the other repository supports [deploy keys](../../deploy_keys/index.md).
 
 To get started:
 
@@ -141,7 +141,7 @@ GitLab generates a 4096-bit RSA key that can be copied by selecting the **Copy S
 You then must add the public SSH key to the other repository's configuration:
 
 - If the other repository is hosted on GitLab, you should add the public SSH key
-  as a [deploy key](../../project/deploy_keys/index.md).
+  as a [deploy key](../../../project/deploy_keys/index.md).
 - If the other repository is hosted elsewhere, you must add the key to
   your user's  `authorized_keys` file. Paste the entire public SSH key into the
   file on its own line and save it.
@@ -161,6 +161,12 @@ update button which is available on the **Mirroring repositories** section of th
 
 ![Repository mirroring force update user interface](img/repository_mirroring_force_update.png)
 
+## Resources
+
+- Configure a [Pull Mirroring Interval](../../../../administration/instance_limits.md#pull-mirroring-interval)
+- [Disable mirrors for a project](../../../user/admin_area/settings/visibility_and_access_controls.md#enable-project-mirroring)
+- [Secrets file and mirroring](../../../../raketasks/backup_restore.md#when-the-secrets-file-is-lost)
+
 ## Troubleshooting
 
 Should an error occur during a push, GitLab displays an **Error** highlight for that repository. Details on the error can then be seen by hovering over the highlight text.
@@ -179,7 +185,7 @@ must update your mirroring username and password to ensure that `%40` characters
 ### Connection blocked because server only allows public key authentication
 
 As the error indicates, the connection is getting blocked between GitLab and the remote repository. Even if a
-[TCP Check](../../../administration/raketasks/maintenance.md#check-tcp-connectivity-to-a-remote-site) is successful,
+[TCP Check](../../../../administration/raketasks/maintenance.md#check-tcp-connectivity-to-a-remote-site) is successful,
 you must check any networking components in the route from GitLab to the remote Server to ensure there's no blockage.
 
 For example, we've seen this error when a Firewall was performing a `Deep SSH Inspection` on outgoing packets.
@@ -187,7 +193,7 @@ For example, we've seen this error when a Firewall was performing a `Deep SSH In
 ### Could not read username: terminal prompts disabled
 
 If you receive this error after creating a new project using
-[GitLab CI/CD for external repositories](../../../ci/ci_cd_for_external_repos/):
+[GitLab CI/CD for external repositories](../../../../ci/ci_cd_for_external_repos/):
 
 ```plaintext
 "2:fetch remote: "fatal: could not read Username for 'https://bitbucket.org': terminal prompts disabled\n": exit status 128."

doc/user/project/repository/mirror/pull.md

@@ -39,7 +39,7 @@ directly to the repository on GitLab. Instead, any commits should be pushed to t
 Changes pushed to the remote repository are pulled into the GitLab repository, either:
 
 - Automatically in a certain period of time.
-- When a [forced update](#force-an-update) is initiated.
+- When a [forced update](index.md#force-an-update) is initiated.
 
 WARNING:
 If you do manually update a branch in the GitLab repository, the branch becomes diverged from
@@ -52,7 +52,7 @@ After the pull mirroring feature has been enabled for a repository, the reposito
 
 Once per minute, a Sidekiq cron job schedules repository mirrors to update, based on:
 
-- The capacity available. This is determined by Sidekiq settings. For GitLab.com, see [GitLab.com Sidekiq settings](../../gitlab_com/index.md#sidekiq).
+- The capacity available. This is determined by Sidekiq settings. For GitLab.com, see [GitLab.com Sidekiq settings](../../../gitlab_com/index.md#sidekiq).
 - The number of repository mirrors already in the queue that are due to be updated. Being due depends on when the repository mirror was last updated and how many times it's been retried.
 
 Repository mirrors are updated as Sidekiq becomes available to process them. If the process of updating the repository mirror:
@@ -93,14 +93,14 @@ and mirroring attempts stop. This failure is visible in either the:
 - Project's main dashboard.
 - Pull mirror settings page.
 
-You can resume the project mirroring again by [forcing an update](#force-an-update).
+You can resume the project mirroring again by [forcing an update](index.md#force-an-update).
 
 ## Trigger an update using the API
 
 > Moved to GitLab Premium in 13.9.
 
 Pull mirroring uses polling to detect new branches and commits added upstream, often minutes
-afterwards. If you notify GitLab by [API](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project),
+afterwards. If you notify GitLab by [API](../../../../api/projects.md#start-the-pull-mirroring-process-for-a-project),
 updates are pulled immediately.
 
-For more information, see [Start the pull mirroring process for a Project](../../../api/projects.md#start-the-pull-mirroring-process-for-a-project).
+For more information, see [Start the pull mirroring process for a Project](../../../../api/projects.md#start-the-pull-mirroring-process-for-a-project).

doc/user/project/repository/mirror/push.md

@@ -15,7 +15,7 @@ For an existing project, you can set up push mirroring as follows:
 1. Enter a repository URL.
 1. In the **Mirror direction** dropdown, select **Push**.
 1. Select an authentication method from the **Authentication method** dropdown.
-   You can authenticate with either a password or an [SSH key](#ssh-authentication).
+   You can authenticate with either a password or an [SSH key](index.md#ssh-authentication).
 1. Select the **Only mirror protected branches** checkbox, if necessary.
 1. Select the **Keep divergent refs** checkbox, if desired.
 1. Select **Mirror repository** to save the configuration.
@@ -23,11 +23,11 @@ For an existing project, you can set up push mirroring as follows:
 When push mirroring is enabled, only push commits directly to the mirrored repository to prevent the
 mirror diverging.
 
-Unlike [pull mirroring](#how-it-works), the mirrored repository is not periodically auto-synced.
+Unlike [pull mirroring](pull.md), the mirrored repository is not periodically auto-synced.
 The mirrored repository receives all changes only when:
 
 - Commits are pushed to GitLab.
-- A [forced update](#force-an-update) is initiated.
+- A [forced update](index.md#force-an-update) is initiated.
 
 Changes pushed to files in the repository are automatically pushed to the remote mirror at least:
 
@@ -40,7 +40,7 @@ section.
 ## Configure push mirrors through the API
 
 You can also create and modify project push mirrors through the
-[remote mirrors API](../../../api/remote_mirrors.md).
+[remote mirrors API](../../../../api/remote_mirrors.md).
 
 ## Keep divergent refs
 
@@ -60,7 +60,7 @@ failed update. Refs that exist in the mirror repository but not in the local
 repository are left untouched.
 
 NOTE:
-After the mirror is created, this option can only be modified via the [API](../../../api/remote_mirrors.md).
+After the mirror is created, this option can only be modified via the [API](../../../../api/remote_mirrors.md).
 
 ## Set up a push mirror from GitLab to GitHub
 
@@ -159,7 +159,7 @@ If it isn't working correctly, a red `error` tag appears and shows the error mes
 
 ## Set up a push mirror to another GitLab instance with 2FA activated
 
-1. On the destination GitLab instance, create a [personal access token](../../profile/personal_access_tokens.md) with `write_repository` scope.
+1. On the destination GitLab instance, create a [personal access token](../../../profile/personal_access_tokens.md) with `write_repository` scope.
 1. On the source GitLab instance:
    1. Fill in the **Git repository URL** field using this format: `https://oauth2@<destination host>/<your_gitlab_group_or_name>/<your_gitlab_project>.git`.
    1. Fill in the **Password** field with the GitLab personal access token created on the destination GitLab instance.