diff --git a/doc/administration/admin_area.md b/doc/administration/admin_area.md
index 9d843bead4d745ac45b28b57abbd9e8ae9518a05..578aff8d50d3fe0fd0f2d98077047db37695f976 100644
--- a/doc/administration/admin_area.md
+++ b/doc/administration/admin_area.md
@@ -331,7 +331,7 @@ To merge topics:
## Administering Gitaly servers
You can list all Gitaly servers in the GitLab instance from the **Admin** area's **Gitaly servers**
-page. For more details, see [Gitaly](gitaly/index.md).
+page. For more details, see [Gitaly](gitaly/_index.md).
To access the **Gitaly servers** page:
diff --git a/doc/administration/backup_restore/backup_gitlab.md b/doc/administration/backup_restore/backup_gitlab.md
index d2712590346bfae59c87f9cbd6798ea03c81018e..127d2515f1302382e3c4dd36e489bd3087149af9 100644
--- a/doc/administration/backup_restore/backup_gitlab.md
+++ b/doc/administration/backup_restore/backup_gitlab.md
@@ -1342,7 +1342,7 @@ In the following cases, consider using file system data transfer or snapshots as
- Your GitLab instance has a problem and using the regular backup and import Rake tasks isn't possible.
WARNING:
-Gitaly Cluster [does not support snapshot backups](../gitaly/index.md#snapshot-backup-and-recovery).
+Gitaly Cluster [does not support snapshot backups](../gitaly/_index.md#snapshot-backup-and-recovery).
When considering using file system data transfer or snapshots:
diff --git a/doc/administration/dedicated/architecture.md b/doc/administration/dedicated/architecture.md
index a1c300e080e44b77d4138bb473b570f02b3d7247..086fb6962d6dddfe6a3392461cd21a1729e6a02d 100644
--- a/doc/administration/dedicated/architecture.md
+++ b/doc/administration/dedicated/architecture.md
@@ -38,7 +38,7 @@ GitLab team members with edit access can update the [source](https://lucid.app/l
### Gitaly setup
-GitLab Dedicated deploys Gitaly [in a sharded setup](../gitaly/index.md#before-deploying-gitaly-cluster), not a Gitaly Cluster. In this setup:
+GitLab Dedicated deploys Gitaly [in a sharded setup](../gitaly/_index.md#before-deploying-gitaly-cluster), not a Gitaly Cluster. In this setup:
- Customer repositories are spread across multiple virtual machines.
- GitLab manages [storage weights](../repository_storage_paths.md#configure-where-new-repositories-are-stored) on behalf of the customer.
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 2b394c6c276e8551d1043fc153d77fc4c7c1f55b..bf1f5cfce49b3e5c3ffaa11d5a8b3ee2879bfac9 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -114,7 +114,7 @@ Geo is designed to be a active-passive, high-availability solution. It operates
## Gitaly Cluster
Geo should not be confused with [Gitaly Cluster](../gitaly/praefect.md). For more information about
-the difference between Geo and Gitaly Cluster, see [Comparison to Geo](../gitaly/index.md#comparison-to-geo).
+the difference between Geo and Gitaly Cluster, see [Comparison to Geo](../gitaly/_index.md#comparison-to-geo).
## How it works
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index 2fae36818911a59114b39bf44da79e09a8b92ed7..bec1e2ce701656a4a506237ff64cdb273126519c 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -189,7 +189,7 @@ successfully, you must replicate their data using some other means.
| [Project wiki repository](../../../user/project/wiki/index.md) | **Yes** (10.2)<sup>2</sup> | **Yes** (10.7)<sup>2</sup> | Not applicable | Not applicable | Migrated to [self-service framework](../../../development/geo/framework.md) in 15.11. See GitLab issue [#367925](https://gitlab.com/gitlab-org/gitlab/-/issues/367925) for more details.<br /><br />Behind feature flag `geo_project_wiki_repository_replication`, enabled by default in (15.11). |
| [Group wiki repository](../../../user/project/wiki/group.md) | [**Yes** (13.10)](https://gitlab.com/gitlab-org/gitlab/-/issues/208147) | [**Yes** (16.3)](https://gitlab.com/gitlab-org/gitlab/-/issues/323897) | Not applicable | Not applicable | Behind feature flag `geo_group_wiki_repository_replication`, enabled by default. |
| [Uploads](../../uploads.md) | **Yes** (10.2) | **Yes** (14.6) | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [**Yes** (16.4)<sup>3</sup>](https://gitlab.com/groups/gitlab-org/-/epics/8056) | Replication is behind the feature flag `geo_upload_replication`, enabled by default. Verification was behind the feature flag `geo_upload_verification`, removed in 14.8. |
-| [LFS objects](../../lfs/index.md) | **Yes** (10.2) | **Yes** (14.6) | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [**Yes** (16.4)<sup>3</sup>](https://gitlab.com/groups/gitlab-org/-/epics/8056) | GitLab versions 11.11.x and 12.0.x are affected by [a bug that prevents any new LFS objects from replicating](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).<br /><br />Replication is behind the feature flag `geo_lfs_object_replication`, enabled by default. Verification was behind the feature flag `geo_lfs_object_verification`, removed in 14.7. |
+| [LFS objects](../../lfs/_index.md) | **Yes** (10.2) | **Yes** (14.6) | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [**Yes** (16.4)<sup>3</sup>](https://gitlab.com/groups/gitlab-org/-/epics/8056) | GitLab versions 11.11.x and 12.0.x are affected by [a bug that prevents any new LFS objects from replicating](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).<br /><br />Replication is behind the feature flag `geo_lfs_object_replication`, enabled by default. Verification was behind the feature flag `geo_lfs_object_verification`, removed in 14.7. |
| [Personal snippets](../../../user/snippets.md) | **Yes** (10.2) | **Yes** (10.2) | Not applicable | Not applicable | |
| [Project snippets](../../../user/snippets.md) | **Yes** (10.2) | **Yes** (10.2) | Not applicable | Not applicable | |
| [CI job artifacts](../../../ci/jobs/job_artifacts.md) | **Yes** (10.4) | **Yes** (14.10) | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [**Yes** (16.4)<sup>3</sup>](https://gitlab.com/groups/gitlab-org/-/epics/8056) | Verification is behind the feature flag `geo_job_artifact_replication`, enabled by default in 14.10. |
diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md
index 4a733837a851b4e47ef500695ec30c08a1bae3bd..98030245f0ed0520bd084cdc74cf15498df8d551 100644
--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -125,7 +125,7 @@ Configure the following services, again using the non-Geo multi-node
documentation:
- [Configuring Redis for GitLab](../../redis/replication_and_failover.md#example-configuration-for-the-gitlab-application) for multiple nodes.
-- [Gitaly](../../gitaly/index.md), which stores data that is
+- [Gitaly](../../gitaly/_index.md), which stores data that is
synchronized from the Geo **primary** site.
NOTE:
diff --git a/doc/administration/geo/replication/object_storage.md b/doc/administration/geo/replication/object_storage.md
index 9f543d55ace8ed5a84838c149cbd77417d25f11d..63779861626bc700b1fb36ece06ff7d3f0ff8158 100644
--- a/doc/administration/geo/replication/object_storage.md
+++ b/doc/administration/geo/replication/object_storage.md
@@ -52,7 +52,7 @@ To enable GitLab replication:
checkbox to enable it.
For LFS, follow the documentation to
-[set up LFS object storage](../../lfs/index.md#storing-lfs-objects-in-remote-object-storage).
+[set up LFS object storage](../../lfs/_index.md#storing-lfs-objects-in-remote-object-storage).
For CI job artifacts, there is similar documentation to configure
[jobs artifact object storage](../../cicd/job_artifacts.md#using-object-storage)
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/_index.md
similarity index 99%
rename from doc/administration/gitaly/index.md
rename to doc/administration/gitaly/_index.md
index 75b470a7ac3efb6c2a4d6cb03f0ce04cec25be50..a02c6724d6b259b3a9bdd94cd1ccafe5ee76d792 100644
--- a/doc/administration/gitaly/index.md
+++ b/doc/administration/gitaly/_index.md
@@ -285,7 +285,7 @@ The following table outlines the major differences between Gitaly Cluster and Ge
| Tool | Nodes | Locations | Latency tolerance | Failover | Consistency | Provides redundancy for |
|:---------------|:---------|:----------|:------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------|:--------------------------------------|:------------------------|
-| Gitaly Cluster | Multiple | Single | [Less than 1 second, ideally single-digit milliseconds](praefect.md#network-latency-and-connectivity) | [Automatic](praefect.md#automatic-failover-and-primary-election-strategies) | [Strong](index.md#strong-consistency) | Data storage in Git |
+| Gitaly Cluster | Multiple | Single | [Less than 1 second, ideally single-digit milliseconds](praefect.md#network-latency-and-connectivity) | [Automatic](praefect.md#automatic-failover-and-primary-election-strategies) | [Strong](_index.md#strong-consistency) | Data storage in Git |
| Geo | Multiple | Multiple | Up to one minute | [Manual](../geo/disaster_recovery/_index.md) | Eventual | Entire GitLab instance |
For more information, see:
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index 375d95f63dca5a8c0d31d5527ac1a1504f564b14..1652615dff2d967a393cff2606863ee543d41b07 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -60,7 +60,7 @@ When configured to run on their own servers, Gitaly servers must be
[upgraded](../../update/package/_index.md) before Gitaly clients in your cluster.
NOTE:
-[Disk requirements](index.md#disk-requirements) apply to Gitaly nodes.
+[Disk requirements](_index.md#disk-requirements) apply to Gitaly nodes.
The process for setting up Gitaly on its own server is:
@@ -875,7 +875,7 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab Self-Managed
-[Gitaly](index.md), the service that provides storage for Git
+[Gitaly](_index.md), the service that provides storage for Git
repositories, can be configured to cache a short rolling window of Git
fetch responses. This can reduce server load when your server receives
lots of CI fetch traffic.
diff --git a/doc/administration/gitaly/gitaly_geo_capabilities.md b/doc/administration/gitaly/gitaly_geo_capabilities.md
index edcb568e05bf40234012dc5e45e56a35addf07dc..37c33f5ceed202044d0e2e9423207f35be4c6371 100644
--- a/doc/administration/gitaly/gitaly_geo_capabilities.md
+++ b/doc/administration/gitaly/gitaly_geo_capabilities.md
@@ -14,7 +14,7 @@ The following tables are intended to guide you to choose the right combination o
| Capability | Availability | Recoverability | Data Resiliency | Performance | Risks/Trade-offs|
|------------|--------------|----------------|-----------------|-------------|-----------------|
-|Gitaly Cluster | Very high - tolerant of node failures | RTO for a single node of 10 s with no manual intervention | Data is stored on multiple nodes | Good - While writes may take slightly longer due to voting, read distribution improves read speeds | **Trade-off** - Slight decrease in write speed for redundant, strongly-consistent storage solution. **Risks** - [Does not support snapshot backups](../gitaly/index.md#snapshot-backup-and-recovery), GitLab backup task can be slow for large data sets |
+|Gitaly Cluster | Very high - tolerant of node failures | RTO for a single node of 10 s with no manual intervention | Data is stored on multiple nodes | Good - While writes may take slightly longer due to voting, read distribution improves read speeds | **Trade-off** - Slight decrease in write speed for redundant, strongly-consistent storage solution. **Risks** - [Does not support snapshot backups](../gitaly/_index.md#snapshot-backup-and-recovery), GitLab backup task can be slow for large data sets |
|Gitaly Shards | Single storage location is a single point of failure | Would need to restore only shards which failed | Single point of failure | Good - can allocate repositories to shards to spread load | **Trade-off** - Need to manually configure repositories into different shards to balance loads / storage space **Risks** - Single point of failure relies on recovery process when single-node failure occurs |
## Geo capabilities
diff --git a/doc/administration/gitaly/kubernetes.md b/doc/administration/gitaly/kubernetes.md
index 8cd9d74d4b25aca5345367ca681b0928b0ad3a19..ae8d44735e08f5f9db17b8bf3282fef2d51abcd7 100644
--- a/doc/administration/gitaly/kubernetes.md
+++ b/doc/administration/gitaly/kubernetes.md
@@ -29,7 +29,7 @@ masks the problem by:
The same approach doesn't fit a container-based lifecycle where a container or pod needs to fully shutdown and start as a new container or pod.
Gitaly Cluster (Praefect) solves the data and service high-availability aspect by replicating data across instances. However, Gitaly Cluster is unsuited to run in Kubernetes
-because of [existing issues and design constraints](index.md#known-issues) that are augmented by a container-based platform.
+because of [existing issues and design constraints](_index.md#known-issues) that are augmented by a container-based platform.
To support a Cloud Native deployment, Gitaly (non-Cluster) is the only option.
By leveraging the right Kubernetes and Gitaly features and configuration, you can minimize service disruption and provide a good user experience.
diff --git a/doc/administration/gitaly/monitoring.md b/doc/administration/gitaly/monitoring.md
index 2752cf7c39b457fc46fdc05babc4ed0ee65a2128..8dcbbf32d6039ab21f00cabb0732a17d656eb66a 100644
--- a/doc/administration/gitaly/monitoring.md
+++ b/doc/administration/gitaly/monitoring.md
@@ -251,7 +251,7 @@ available from which metrics can be scraped:
The following metrics are available from the `/metrics` endpoint:
-- `gitaly_praefect_read_distribution`, a counter to track [distribution of reads](index.md#distributed-reads).
+- `gitaly_praefect_read_distribution`, a counter to track [distribution of reads](_index.md#distributed-reads).
It has two labels:
- `virtual_storage`.
@@ -266,7 +266,7 @@ The following metrics are available from the `/metrics` endpoint:
- `gitaly_praefect_connections_total`, the total number of connections to Praefect.
- `gitaly_praefect_method_types`, a count of accessor and mutator RPCs per node.
-To monitor [strong consistency](index.md#strong-consistency), you can use the following Prometheus metrics:
+To monitor [strong consistency](_index.md#strong-consistency), you can use the following Prometheus metrics:
- `gitaly_praefect_transactions_total`, the number of transactions created and voted on.
- `gitaly_praefect_subtransactions_per_transaction_total`, the number of times nodes cast a vote for
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 64a65df7a908bbcbb04e567439b63226d0929bd8..346c338581ce8638250b078d9dbdb9eedfade709 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -20,7 +20,7 @@ Configure Gitaly Cluster using either:
- [1000 RPS or 50,000 users](../reference_architectures/50k_users.md#configure-gitaly-cluster).
- The custom configuration instructions that follow on this page.
-Smaller GitLab installations may need only [Gitaly itself](index.md).
+Smaller GitLab installations may need only [Gitaly itself](_index.md).
NOTE:
Gitaly Cluster is not yet supported in Kubernetes, Amazon ECS, or similar container environments. For more information, see
@@ -36,7 +36,7 @@ The minimum recommended configuration for a Gitaly Cluster requires:
- 3 Gitaly nodes (1 primary, 2 secondary)
NOTE:
-[Disk requirements](index.md#disk-requirements) apply to Gitaly nodes.
+[Disk requirements](_index.md#disk-requirements) apply to Gitaly nodes.
You should configure an odd number of Gitaly nodes so that transactions have a tie-breaker in case one of the
Gitaly nodes fails in a mutating RPC call.
@@ -54,7 +54,7 @@ Network latency for Gitaly Cluster should ideally be measurable in single-digit
important for:
- Gitaly node health checks. Nodes must be able to respond within 1 second.
-- Reference transactions that enforce [strong consistency](index.md#strong-consistency). Lower latencies mean Gitaly
+- Reference transactions that enforce [strong consistency](_index.md#strong-consistency). Lower latencies mean Gitaly
nodes can agree on changes faster.
Achieving acceptable latency between Gitaly nodes:
@@ -64,9 +64,9 @@ Achieving acceptable latency between Gitaly nodes:
are designed for this type of synchronization. Latency of less than 2 ms should be sufficient for Gitaly Cluster.
If you can't provide low network latencies for replication (for example, between distant locations), consider Geo. For
-more information, see [Comparison to Geo](index.md#comparison-to-geo).
+more information, see [Comparison to Geo](_index.md#comparison-to-geo).
-Gitaly Cluster [components](index.md#components) communicate with each other over many routes. Your firewall rules must
+Gitaly Cluster [components](_index.md#components) communicate with each other over many routes. Your firewall rules must
allow the following for Gitaly Cluster to function properly:
| From | To | Default port | TLS port |
@@ -624,7 +624,7 @@ Updates to example must be made at:
WARNING:
If you have data on an already existing storage called
`default`, you should configure the virtual storage with another name and
- [migrate the data to the Gitaly Cluster storage](index.md#migrate-to-gitaly-cluster)
+ [migrate the data to the Gitaly Cluster storage](_index.md#migrate-to-gitaly-cluster)
afterwards.
Replace `PRAEFECT_INTERNAL_TOKEN` with a strong secret, which is used by
@@ -1036,7 +1036,7 @@ To complete this section you need:
These should be dedicated nodes, do not run other services on these nodes.
Every Gitaly server assigned to the Praefect cluster needs to be configured. The
-configuration is the same as a standard [standalone Gitaly server](index.md),
+configuration is the same as a standard [standalone Gitaly server](_index.md),
except:
- The storage names are exposed to Praefect, not GitLab
@@ -1309,7 +1309,7 @@ Particular attention should be shown to:
WARNING:
If you have existing data stored on the default Gitaly storage,
- you should [migrate the data to your Gitaly Cluster storage](index.md#migrate-to-gitaly-cluster)
+ you should [migrate the data to your Gitaly Cluster storage](_index.md#migrate-to-gitaly-cluster)
first.
```ruby
@@ -1554,7 +1554,7 @@ current assignments: gitaly-1, gitaly-2
### Repository storage recommendations
The size of the required storage can vary between instances and depends on the set
-[replication factor](index.md#replication-factor). You might want to include implementing
+[replication factor](_index.md#replication-factor). You might want to include implementing
repository storage redundancy.
For a replication factor:
@@ -1643,7 +1643,7 @@ praefect['configuration'] = {
WARNING:
Deletions were disabled by default prior to GitLab 15.9 due to a race condition with repository renames
that can cause incorrect deletions, which is especially prominent in Geo instances as Geo performs more renames
-than instances without Geo. In GitLab 15.0 to 15.5, you should enable deletions only if the [`gitaly_praefect_generated_replica_paths` feature flag](index.md#praefect-generated-replica-paths) is enabled. The feature flag was removed in GitLab 15.6 making deletions always safe to enable.
+than instances without Geo. In GitLab 15.0 to 15.5, you should enable deletions only if the [`gitaly_praefect_generated_replica_paths` feature flag](_index.md#praefect-generated-replica-paths) is enabled. The feature flag was removed in GitLab 15.6 making deletions always safe to enable.
By default, the worker deletes invalid metadata records. It also logs the deleted records and outputs Prometheus
metrics.
diff --git a/doc/administration/gitaly/troubleshooting_gitaly_cluster.md b/doc/administration/gitaly/troubleshooting_gitaly_cluster.md
index c36d6eeafef227ca5658060ef5031df6ca495153..60e79126f9f4d52adb4e4773112ac8c83b9de738 100644
--- a/doc/administration/gitaly/troubleshooting_gitaly_cluster.md
+++ b/doc/administration/gitaly/troubleshooting_gitaly_cluster.md
@@ -114,7 +114,7 @@ To determine the primary node of a repository, use the [`praefect metadata`](#vi
## View repository metadata
-Gitaly Cluster maintains a [metadata database](index.md#components) about the repositories stored on the cluster. Use the `praefect metadata` subcommand
+Gitaly Cluster maintains a [metadata database](_index.md#components) about the repositories stored on the cluster. Use the `praefect metadata` subcommand
to inspect the metadata for troubleshooting.
You can retrieve a repository's metadata by its Praefect-assigned repository ID:
@@ -124,7 +124,7 @@ sudo -u git -- /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefec
```
When the physical path on the physical storage starts with `@cluster`, you can
-[find the repository ID in the physical path](index.md#praefect-generated-replica-paths).
+[find the repository ID in the physical path](_index.md#praefect-generated-replica-paths).
You can also retrieve a repository's metadata by its virtual storage and relative path:
@@ -213,7 +213,7 @@ The documented examples specify `-virtual-storage default`. Check the Praefect s
## Check that repositories are in sync
-Is [some cases](index.md#known-issues) the Praefect database can get out of sync with the underlying Gitaly nodes. To check that
+Is [some cases](_index.md#known-issues) the Praefect database can get out of sync with the underlying Gitaly nodes. To check that
a given repository is fully synced on all nodes, run the [`gitlab:praefect:replicas` Rake task](../raketasks/praefect.md#replica-checksums) on your Rails node.
This Rake task checksums the repository on all Gitaly nodes.
diff --git a/doc/administration/gitlab_duo_self_hosted/index.md b/doc/administration/gitlab_duo_self_hosted/_index.md
similarity index 100%
rename from doc/administration/gitlab_duo_self_hosted/index.md
rename to doc/administration/gitlab_duo_self_hosted/_index.md
diff --git a/doc/administration/gitlab_duo_self_hosted/configure_duo_features.md b/doc/administration/gitlab_duo_self_hosted/configure_duo_features.md
index 1eabf1823ab765ccc29d2a587543dc28c547c92b..67288031447ddafa453fb8fad6299c30b83b791d 100644
--- a/doc/administration/gitlab_duo_self_hosted/configure_duo_features.md
+++ b/doc/administration/gitlab_duo_self_hosted/configure_duo_features.md
@@ -18,7 +18,7 @@ DETAILS:
To configure your GitLab instance to access the available self-hosted models in your infrastructure:
-1. [Confirm that a fully self-hosted configuration is appropriate for your use case](index.md#decide-on-your-configuration-type).
+1. [Confirm that a fully self-hosted configuration is appropriate for your use case](_index.md#decide-on-your-configuration-type).
1. Configure your GitLab instance.
1. Configure the self-hosted model.
1. Configure the GitLab Duo features to use your self-hosted model.
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 04abf471eadaa7cf1eb2c82cdeedc7139d1f4ae0..1b623941f4f74312fb5cb0bc4d7ead057742fb61 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -101,7 +101,7 @@ This setting limits the request rate on the Packages API per user or IP. For mor
This setting limits the request rate on the [Git LFS](../topics/git/lfs/_index.md)
requests per user. For more information, read
-[GitLab Git Large File Storage (LFS) Administration](lfs/index.md).
+[GitLab Git Large File Storage (LFS) Administration](lfs/_index.md).
- **Default rate limit**: Disabled by default.
diff --git a/doc/administration/lfs/index.md b/doc/administration/lfs/_index.md
similarity index 100%
rename from doc/administration/lfs/index.md
rename to doc/administration/lfs/_index.md
diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md
index 3b71af684e0d588545ef77ee4413ae781ca1a434..3b964224166d30d5f0cda5af9e6260d336a0b935 100644
--- a/doc/administration/monitoring/performance/performance_bar.md
+++ b/doc/administration/monitoring/performance/performance_bar.md
@@ -36,7 +36,7 @@ From left to right, the performance bar displays:
GitLab features. The name shown is the same name used to configure database
connections in GitLab.
- **Gitaly calls**: the time taken (in milliseconds) and the total number of
- [Gitaly](../../gitaly/index.md) calls. Select to display a modal window with more
+ [Gitaly](../../gitaly/_index.md) calls. Select to display a modal window with more
details.
- **Redis calls**: the time taken (in milliseconds) and the total number of
Redis calls. Select to display a modal window with more details.
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 652d4bd6de7568ccc394b16c2530a68fc94be65a..0e7a219be6e2061d5b407efd2031f2f24644ff2d 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -113,7 +113,7 @@ The following table lists the valid `objects` that can be used:
| `artifacts` | [CI/CD job artifacts](cicd/job_artifacts.md) |
| `external_diffs` | [Merge request diffs](merge_request_diffs.md) |
| `uploads` | [User uploads](uploads.md) |
-| `lfs` | [Git Large File Storage objects](lfs/index.md) |
+| `lfs` | [Git Large File Storage objects](lfs/_index.md) |
| `packages` | [Project packages (for example, PyPI, Maven, or NuGet)](packages/index.md) |
| `dependency_proxy` | [Dependency Proxy](packages/dependency_proxy.md) |
| `terraform_state` | [Terraform state files](terraform_state.md) |
@@ -172,7 +172,7 @@ supported by the consolidated form, refer to the following guides:
| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | **{dotted-circle}** No |
| [Secure Files](cicd/secure_files.md#using-object-storage) | **{check-circle}** Yes |
| [Job artifacts](cicd/job_artifacts.md#using-object-storage) including archived job logs | **{check-circle}** Yes |
-| [LFS objects](lfs/index.md#storing-lfs-objects-in-remote-object-storage) | **{check-circle}** Yes |
+| [LFS objects](lfs/_index.md#storing-lfs-objects-in-remote-object-storage) | **{check-circle}** Yes |
| [Uploads](uploads.md#using-object-storage) | **{check-circle}** Yes |
| [Merge request diffs](merge_request_diffs.md#using-object-storage) | **{check-circle}** Yes |
| [Packages](packages/index.md#use-object-storage) (optional feature) | **{check-circle}** Yes |
@@ -745,7 +745,7 @@ The following example uses AWS S3 to enable object storage for all supported ser
To migrate existing local data to object storage see the following guides:
- [Job artifacts](cicd/job_artifacts.md#migrating-to-object-storage) including archived job logs
-- [LFS objects](lfs/index.md#migrating-to-object-storage)
+- [LFS objects](lfs/_index.md#migrating-to-object-storage)
- [Uploads](raketasks/uploads/migrate.md#migrate-to-object-storage)
- [Merge request diffs](merge_request_diffs.md#using-object-storage)
- [Packages](packages/index.md#migrate-local-packages-to-object-storage) (optional feature)
@@ -938,7 +938,7 @@ This can result in some of the following problems:
An error occurred while loading the file. Please try again later.
```
- See [the LFS documentation](lfs/index.md#error-viewing-a-pdf-file) for more details.
+ See [the LFS documentation](lfs/_index.md#error-viewing-a-pdf-file) for more details.
Additionally for a short time period users could share pre-signed, time-limited object storage URLs
with others without authentication. Also bandwidth charges may be incurred
diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md
index 2c33353599268231efe88070b3c9166a7474774d..6f05ba7a44f95d7d49646f75d92653092191a198 100644
--- a/doc/administration/operations/moving_repositories.md
+++ b/doc/administration/operations/moving_repositories.md
@@ -29,7 +29,7 @@ For more information, see:
querying and scheduling snippet repository moves.
- [The API documentation](../../api/group_repository_storage_moves.md) details the endpoints for
querying and scheduling group repository moves.
-- [Migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
+- [Migrate to Gitaly Cluster](../gitaly/_index.md#migrate-to-gitaly-cluster).
### Moving Repositories
diff --git a/doc/administration/raketasks/check.md b/doc/administration/raketasks/check.md
index 4468f3bdad77239a1a4fb34111b019b20988f2cd..508e5731c5c61184547034eaed05acf3765c60ee 100644
--- a/doc/administration/raketasks/check.md
+++ b/doc/administration/raketasks/check.md
@@ -432,7 +432,7 @@ To delete these references to missing local and/or remote artifacts (`job.log` f
### Delete references to missing LFS objects
If `gitlab-rake gitlab:lfs:check VERBOSE=1` detects LFS objects that exist in the database
-but not on disk, [follow the procedure in the LFS documentation](../lfs/index.md#missing-lfs-objects)
+but not on disk, [follow the procedure in the LFS documentation](../lfs/_index.md#missing-lfs-objects)
to remove the database entries.
### Update dangling object storage references
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index 73db321ededd6e4ecd6d3ee096d0a8cd42270192..3bd891d32e4c62139a80ed2583926f20737ec30b 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -52,7 +52,7 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi
The sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
6. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes).
@@ -1182,14 +1182,14 @@ WARNING:
If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance.
Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
-Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster).
For guidance on:
- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
instead of this section. Use the same Gitaly specs.
- Migrating existing repositories that aren't managed by Gitaly Cluster, see
- [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
+ [migrate to Gitaly Cluster](../gitaly/_index.md#migrate-to-gitaly-cluster).
The recommended cluster setup includes the following components:
@@ -1510,7 +1510,7 @@ To configure the Praefect nodes, on each one:
### Configure Gitaly
-The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
+The [Gitaly](../gitaly/_index.md) server nodes that make up the cluster have
requirements that are dependent on data and load.
WARNING:
@@ -2315,7 +2315,7 @@ services where applicable):
Also, the sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
<!-- markdownlint-enable MD029 -->
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index f81e183487492e6db38d47134b361de8c7f38339..941fc88c5f26f23d397e1c1ef9bdfbb251dbf9a9 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -52,7 +52,7 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi
Also, the sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
6. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes).
@@ -1190,14 +1190,14 @@ WARNING:
If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance.
Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
-Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster).
For guidance on:
- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
instead of this section. Use the same Gitaly specs.
- Migrating existing repositories that aren't managed by Gitaly Cluster, see
- [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
+ [migrate to Gitaly Cluster](../gitaly/_index.md#migrate-to-gitaly-cluster).
The recommended cluster setup includes the following components:
@@ -1516,7 +1516,7 @@ To configure the Praefect nodes, on each one:
### Configure Gitaly
-The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
+The [Gitaly](../gitaly/_index.md) server nodes that make up the cluster have
requirements that are dependent on data and load.
WARNING:
@@ -2322,7 +2322,7 @@ services where applicable):
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
<!-- markdownlint-enable MD029 -->
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index 4ba018809a34f461b0362b1f0a7ef798b512909a..6a7ba71de60898a440b8b25a131ae687f147d4a9 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -420,7 +420,7 @@ are supported and can be added if needed.
## Configure Gitaly
-[Gitaly](../gitaly/index.md) server node requirements are dependent on data size,
+[Gitaly](../gitaly/_index.md) server node requirements are dependent on data size,
specifically the number of projects and those projects' sizes.
WARNING:
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index d3bed953bc1eb2693cba799a88c7f1d48f3d5aeb..487fddc6aec9ec3fe93b0d40ea58a2e6cacaccbc 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -50,7 +50,7 @@ For a full list of reference architectures, see
Sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
1. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
6. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes).
@@ -1021,14 +1021,14 @@ WARNING:
If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance.
Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
-Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster).
For guidance on:
- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
instead of this section. Use the same Gitaly specs.
- Migrating existing repositories that aren't managed by Gitaly Cluster, see
- [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
+ [migrate to Gitaly Cluster](../gitaly/_index.md#migrate-to-gitaly-cluster).
The recommended cluster setup includes the following components:
@@ -1346,7 +1346,7 @@ To configure the Praefect nodes, on each one:
### Configure Gitaly
-The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
+The [Gitaly](../gitaly/_index.md) server nodes that make up the cluster have
requirements that are dependent on data and load.
WARNING:
@@ -2213,7 +2213,7 @@ services where applicable):
Sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
<!-- markdownlint-enable MD029 -->
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 33db9017484cc2509aab500f4083269aee535173..7dd943f14eaaf5c8b4a2208a80b8f874cb01fe8d 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -51,7 +51,7 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
6. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes).
@@ -1197,14 +1197,14 @@ WARNING:
If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance.
Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
-Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster).
For guidance on:
- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
instead of this section. Use the same Gitaly specs.
- Migrating existing repositories that aren't managed by Gitaly Cluster, see
- [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
+ [migrate to Gitaly Cluster](../gitaly/_index.md#migrate-to-gitaly-cluster).
The recommended cluster setup includes the following components:
@@ -1523,7 +1523,7 @@ To configure the Praefect nodes, on each one:
### Configure Gitaly
-The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
+The [Gitaly](../gitaly/_index.md) server nodes that make up the cluster have
requirements that are dependent on data and load.
WARNING:
@@ -2337,7 +2337,7 @@ services where applicable):
3. Can be optionally run on reputable third-party load balancing services (LB PaaS). See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
<!-- markdownlint-enable MD029 -->
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index bda1a6dce091d39b6d63ef4b5ab634693e430e98..e40fb5ce34154242b72429a5f9ef92ede58b53dc 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -50,7 +50,7 @@ specifically the [Before you start](index.md#before-you-start) and [Deciding whi
Also, the sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
6. Can be placed in Auto Scaling Groups (ASGs) as the component doesn't store any [stateful data](index.md#autoscaling-of-stateful-nodes).
@@ -1021,14 +1021,14 @@ WARNING:
If this applies to you, we strongly recommended referring to the linked documentation as well as reaching out to your [Customer Success Manager](https://handbook.gitlab.com/job-families/sales/customer-success-management/) or our [Support team](https://about.gitlab.com/support/) for further guidance.
Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
-Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster).
+Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster).
For guidance on:
- Implementing sharded Gitaly instead, follow the [separate Gitaly documentation](../gitaly/configure_gitaly.md)
instead of this section. Use the same Gitaly specs.
- Migrating existing repositories that aren't managed by Gitaly Cluster, see
- [migrate to Gitaly Cluster](../gitaly/index.md#migrate-to-gitaly-cluster).
+ [migrate to Gitaly Cluster](../gitaly/_index.md#migrate-to-gitaly-cluster).
The recommended cluster setup includes the following components:
@@ -1347,7 +1347,7 @@ To configure the Praefect nodes, on each one:
### Configure Gitaly
-The [Gitaly](../gitaly/index.md) server nodes that make up the cluster have
+The [Gitaly](../gitaly/_index.md) server nodes that make up the cluster have
requirements that are dependent on data and load.
WARNING:
@@ -2186,7 +2186,7 @@ services where applicable):
Also, the sizing depends on selected Load Balancer and additional factors such as Network Bandwidth. Refer to [Load Balancers](index.md#load-balancers) for more information.
4. Should be run on reputable Cloud Provider or Self Managed solutions. See [Configure the object storage](#configure-the-object-storage) for more information.
5. Gitaly Cluster provides the benefits of fault tolerance, but comes with additional complexity of setup and management.
- Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
+ Review the existing [technical limitations and considerations before deploying Gitaly Cluster](../gitaly/_index.md#before-deploying-gitaly-cluster). If you want sharded Gitaly, use the same specs listed above for `Gitaly`.
6. Gitaly specifications are based on high percentiles of both usage patterns and repository sizes in good health.
However, if you have [large monorepos](index.md#large-monorepos) (larger than several gigabytes) or [additional workloads](index.md#additional-workloads) these can *significantly* impact Git and Gitaly performance and further adjustments will likely be required.
<!-- markdownlint-enable MD029 -->
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 23e96d9136d603e5360bc89df24fdd4ddb257519..7a716af0c7977f0e1c441642235c43770d7ac5f7 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -320,7 +320,7 @@ Any "burstable" instance types are not recommended due to inconsistent performan
Most standard disk types are expected to work for GitLab. However, be aware of the following specific call-outs:
-- [Gitaly](../gitaly/index.md#disk-requirements) requires at least 8,000 input/output operations per second (IOPS) for read operations, and 2,000 IOPS for write operations.
+- [Gitaly](../gitaly/_index.md#disk-requirements) requires at least 8,000 input/output operations per second (IOPS) for read operations, and 2,000 IOPS for write operations.
- We don't recommend the use of any disk types that are "burstable" due to inconsistent performance.
Other disk types are expected to work with GitLab. Choose based on your requirements such as durability or cost.
@@ -835,7 +835,7 @@ For more information, see the following documentation:
- [Redis to multi-node Redis w/ Redis Sentinel](../redis/replication_and_failover.md#switching-from-an-existing-single-machine-installation)
- [Postgres to multi-node Postgres w/ Consul + PgBouncer](../postgresql/moving.md)
-- [Gitaly to Gitaly Cluster w/ Praefect](../gitaly/index.md#migrate-to-gitaly-cluster)
+- [Gitaly to Gitaly Cluster w/ Praefect](../gitaly/_index.md#migrate-to-gitaly-cluster)
### Upgrades
diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md
index 846eedb29aa279f2e7b80edba94c4ae681f0d38d..703bcaee84e9651cbe84c082ec5a9de98fad2dcf 100644
--- a/doc/administration/repository_checks.md
+++ b/doc/administration/repository_checks.md
@@ -64,7 +64,7 @@ Repositories with known check failures can be found at
## Run a check using the command line
You can run [`git fsck`](https://git-scm.com/docs/git-fsck) using the command line on repositories on
-[Gitaly servers](gitaly/index.md). To locate the repositories:
+[Gitaly servers](gitaly/_index.md). To locate the repositories:
1. Go to the storage location for repositories:
- For Linux package installations, repositories are stored in the `/var/opt/gitlab/git-data/repositories` directory
diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md
index d41499041d260961f047b0eabc2cd47fc568ade8..8e935867c7f120a499cd91e947b16fd628d17641 100644
--- a/doc/administration/repository_storage_paths.md
+++ b/doc/administration/repository_storage_paths.md
@@ -12,8 +12,8 @@ DETAILS:
GitLab stores [repositories](../user/project/repository/index.md) on repository storage. Repository
storage is either:
-- Physical storage configured with a `gitaly_address` that points to a [Gitaly node](gitaly/index.md).
-- [Virtual storage](gitaly/index.md#virtual-storage) that stores repositories on a Gitaly Cluster.
+- Physical storage configured with a `gitaly_address` that points to a [Gitaly node](gitaly/_index.md).
+- [Virtual storage](gitaly/_index.md#virtual-storage) that stores repositories on a Gitaly Cluster.
WARNING:
Repository storage could be configured as a `path` that points directly to the directory where the repositories are
@@ -176,7 +176,7 @@ For example:
If Gitaly Cluster is used, Praefect manages storage locations. The internal path used by Praefect for the repository
differs from the hashed path. For more information, see
-[Praefect-generated replica paths](gitaly/index.md#praefect-generated-replica-paths).
+[Praefect-generated replica paths](gitaly/_index.md#praefect-generated-replica-paths).
### Object storage support
@@ -221,7 +221,7 @@ storage pattern using two characters and two-level folders, following the Git im
"shared/lfs-objects/89/09/029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c"
```
-LFS objects are also [S3-compatible](lfs/index.md#storing-lfs-objects-in-remote-object-storage).
+LFS objects are also [S3-compatible](lfs/_index.md#storing-lfs-objects-in-remote-object-storage).
## Configure where new repositories are stored
@@ -252,4 +252,4 @@ See [the tracking issue](https://gitlab.com/gitlab-org/gitlab/-/issues/36175) fo
## Move repositories
To move a repository to a different repository storage (for example, from `default` to `storage2`), use the
-same process as [migrating to Gitaly Cluster](gitaly/index.md#migrate-to-gitaly-cluster).
+same process as [migrating to Gitaly Cluster](gitaly/_index.md#migrate-to-gitaly-cluster).
diff --git a/doc/administration/self_hosted_models/index.md b/doc/administration/self_hosted_models/index.md
index 467f046939821ff48e89da13fd59130d551dde2f..229060208f1b5c0d9d1274870924d447ad0a36d1 100644
--- a/doc/administration/self_hosted_models/index.md
+++ b/doc/administration/self_hosted_models/index.md
@@ -5,7 +5,7 @@ remove_date: '2025-05-05'
<!-- markdownlint-disable -->
-This document was moved to [another location](../gitlab_duo_self_hosted/index.md).
+This document was moved to [another location](../gitlab_duo_self_hosted/_index.md).
<!-- This redirect file can be deleted after <2025-05-05>. -->
<!-- Redirects that point to other docs in the same project expire in three months. -->
diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md
index 60d8a29a0b24ee19a870a2d53f62eb477093cea2..1d0ca92e83c669bbc761c19a7c1a7649140f3618 100644
--- a/doc/administration/server_hooks.md
+++ b/doc/administration/server_hooks.md
@@ -110,7 +110,7 @@ If the server hook code is properly implemented, it should execute when the Git
### Server hooks on a Gitaly Cluster
-If you use [Gitaly Cluster](gitaly/index.md), an individual repository may be replicated to multiple Gitaly storages in Praefect.
+If you use [Gitaly Cluster](gitaly/_index.md), an individual repository may be replicated to multiple Gitaly storages in Praefect.
Consequentially, the hook scripts must be copied to every Gitaly node that has a replica of the repository.
To accomplish this, follow the same steps for setting custom repository hooks for the applicable version and repeat for each storage.
@@ -119,7 +119,7 @@ The location to copy the scripts to depends on where repositories are stored:
- In GitLab 15.2 and earlier, Gitaly Cluster uses the [hashed storage path](repository_storage_paths.md#hashed-storage)
reported by the GitLab application.
- In GitLab 15.3 and later, new repositories are created using
- [Praefect-generated replica paths](gitaly/index.md#praefect-generated-replica-paths),
+ [Praefect-generated replica paths](gitaly/_index.md#praefect-generated-replica-paths),
which are not the hashed storage path. The replica path can be identified by
[querying the Praefect repository metadata](gitaly/troubleshooting_gitaly_cluster.md#view-repository-metadata)
using `-relative-path` to specify the expected GitLab hashed storage path.
diff --git a/doc/administration/settings/gitaly_timeouts.md b/doc/administration/settings/gitaly_timeouts.md
index afc86f7d5a54a6f8f1dd4cb9328be1a3dc96ffa2..f58fe86acbee6abfdf9d98ee6e0fb41f040ba4fc 100644
--- a/doc/administration/settings/gitaly_timeouts.md
+++ b/doc/administration/settings/gitaly_timeouts.md
@@ -9,7 +9,7 @@ DETAILS:
**Tier:** Free, Premium, Ultimate
**Offering:** GitLab Self-Managed
-[Gitaly](../gitaly/index.md) provides two types of configurable timeouts:
+[Gitaly](../gitaly/_index.md) provides two types of configurable timeouts:
- Call timeouts, configured by using the GitLab UI.
- Negotiation timeouts, configured by using Gitaly configuration files.
diff --git a/doc/api/group_repository_storage_moves.md b/doc/api/group_repository_storage_moves.md
index 1a35838977450dad0200194ad44ac6ed2ce0abfe..0ddfc7eb26b4c420eece71e558d7ac28b29a5b3a 100644
--- a/doc/api/group_repository_storage_moves.md
+++ b/doc/api/group_repository_storage_moves.md
@@ -11,7 +11,7 @@ DETAILS:
**Offering:** GitLab Self-Managed, GitLab Dedicated
Group wiki repositories can be moved between storages. This API can help you, for example,
-[migrate to Gitaly Cluster](../administration/gitaly/index.md#migrate-to-gitaly-cluster)
+[migrate to Gitaly Cluster](../administration/gitaly/_index.md#migrate-to-gitaly-cluster)
or migrate a [group wiki](../user/project/wiki/group.md). This API does not manage
project repositories in a group. To schedule project moves, use the
[project repository storage moves API](project_repository_storage_moves.md).
diff --git a/doc/api/project_repository_storage_moves.md b/doc/api/project_repository_storage_moves.md
index ce285fb7b02776301f8c83cf011c2eb92a1022c1..fc5093b9c0be5584de585492d39b6cec50bd16c2 100644
--- a/doc/api/project_repository_storage_moves.md
+++ b/doc/api/project_repository_storage_moves.md
@@ -10,7 +10,7 @@ DETAILS:
**Offering:** GitLab Self-Managed, GitLab Dedicated
Project repositories including wiki and design repositories can be moved between storages. This API can help you when
-[migrating to Gitaly Cluster](../administration/gitaly/index.md#migrate-to-gitaly-cluster), for example.
+[migrating to Gitaly Cluster](../administration/gitaly/_index.md#migrate-to-gitaly-cluster), for example.
As project repository storage moves are processed, they transition through different states. Values
of `state` are:
diff --git a/doc/api/projects.md b/doc/api/projects.md
index 7a5330b4b94c2bf38b553ebedebfd58df42b3c95..a33ad024493fa623551909cffa0932e6c12d44fb 100644
--- a/doc/api/projects.md
+++ b/doc/api/projects.md
@@ -2530,7 +2530,7 @@ Supported attributes:
## Get the path to repository storage
Get the path to repository storage for specified project if Gitaly Cluster is not being used. If Gitaly Cluster is being used, see
-[Praefect-generated replica paths](../administration/gitaly/index.md#praefect-generated-replica-paths).
+[Praefect-generated replica paths](../administration/gitaly/_index.md#praefect-generated-replica-paths).
Available for administrators only.
diff --git a/doc/api/snippet_repository_storage_moves.md b/doc/api/snippet_repository_storage_moves.md
index f0c25e445affc6ac6a42eb6f903fc380669ecd14..208e812fe906e9e9ae7f938083e213b4cf897af0 100644
--- a/doc/api/snippet_repository_storage_moves.md
+++ b/doc/api/snippet_repository_storage_moves.md
@@ -10,7 +10,7 @@ DETAILS:
**Offering:** GitLab Self-Managed, GitLab Dedicated
Snippet repositories can be moved between storages. This API can help you when
-[migrating to Gitaly Cluster](../administration/gitaly/index.md#migrate-to-gitaly-cluster), for
+[migrating to Gitaly Cluster](../administration/gitaly/_index.md#migrate-to-gitaly-cluster), for
example.
As snippet repository storage moves are processed, they transition through different states. Values
diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md
index 273f0dc6b8d802343e70262d21e23d162b80da7a..c060bc43788e543136e08b7c8d5717774d1e6069 100644
--- a/doc/development/api_graphql_styleguide.md
+++ b/doc/development/api_graphql_styleguide.md
@@ -561,7 +561,7 @@ with little-to-no _work_, for example in most cases; `id` or `title`, can be giv
### `calls_gitaly`
-Fields that have the potential to perform a [Gitaly](../administration/gitaly/index.md) call when resolving _must_ be marked as
+Fields that have the potential to perform a [Gitaly](../administration/gitaly/_index.md) call when resolving _must_ be marked as
such by passing `calls_gitaly: true` to `field` when defining it.
For example:
diff --git a/doc/development/architecture.md b/doc/development/architecture.md
index 8eae66c146d0c740a133fb0cfa8ac09cc25dad45..0fdeeb83d211312077364a66b2e6e7edc65f9053 100644
--- a/doc/development/architecture.md
+++ b/doc/development/architecture.md
@@ -495,7 +495,7 @@ Elasticsearch is a distributed RESTful search engine built for the cloud.
- [Project page](https://gitlab.com/gitlab-org/gitaly/blob/master/README.md)
- Configuration:
- - [Omnibus](../administration/gitaly/index.md)
+ - [Omnibus](../administration/gitaly/_index.md)
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/gitaly/)
- [Source](../install/installation.md#install-gitaly)
- Layer: Core Service (Data)
@@ -507,7 +507,7 @@ Gitaly is a service designed by GitLab to remove our need for NFS for Git storag
- [Project page](https://gitlab.com/gitlab-org/gitaly/blob/master/README.md)
- Configuration:
- - [Omnibus](../administration/gitaly/index.md)
+ - [Omnibus](../administration/gitaly/_index.md)
- [Source](../install/installation.md#install-gitaly)
- Layer: Core Service (Data)
- Process: `praefect`
diff --git a/doc/development/backend/create_source_code_be/_index.md b/doc/development/backend/create_source_code_be/_index.md
index d8077a0c717376b6d068906887f6a043d546dcb6..a1fc4a89f35a13ee4ab54e828063a4d60cb4d17a 100644
--- a/doc/development/backend/create_source_code_be/_index.md
+++ b/doc/development/backend/create_source_code_be/_index.md
@@ -54,7 +54,7 @@ Details about Protected Branches models can be found in the [Code Owners](../../
### Gitaly touch points
-[Gitaly](../../../administration/gitaly/index.md) provides high-level RPC access to Git repositories.
+[Gitaly](../../../administration/gitaly/_index.md) provides high-level RPC access to Git repositories.
It is present in every GitLab installation and coordinates Git repository storage and retrieval.
Gitaly implements a client-server architecture with Gitaly as the server and Gitaly clients, also
known as _Gitaly consumers_, including:
diff --git a/doc/development/backend/create_source_code_be/gitaly_touch_points.md b/doc/development/backend/create_source_code_be/gitaly_touch_points.md
index 25a352b2faa0b562f78e28bb63ebd549207d6b92..534d089f947ef34acffc328e7a047193859912b5 100644
--- a/doc/development/backend/create_source_code_be/gitaly_touch_points.md
+++ b/doc/development/backend/create_source_code_be/gitaly_touch_points.md
@@ -7,7 +7,7 @@ title: Source Code - Gitaly Touch Points
## RPCs
-Gitaly is a wrapper around the `git` binary, running in a [Gitaly Cluster](../../../administration/gitaly/index.md). It provides managed access to the file system housing the `git` repositories, using Go Remote Procedure Calls (RPCs). Other functions are access optimization, caching, and a form of pagination against the file system.
+Gitaly is a wrapper around the `git` binary, running in a [Gitaly Cluster](../../../administration/gitaly/_index.md). It provides managed access to the file system housing the `git` repositories, using Go Remote Procedure Calls (RPCs). Other functions are access optimization, caching, and a form of pagination against the file system.
The comprehensive [Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/beginners_guide.md) is focused on making updates to Gitaly, and offers many insights into how to understand the Gitaly code.
diff --git a/doc/development/lfs.md b/doc/development/lfs.md
index ed8820934ff0805fc9282e13db2a3759a7bea5fb..c4394636fac6c230ff946a7cc4ad4dbf9b118169 100644
--- a/doc/development/lfs.md
+++ b/doc/development/lfs.md
@@ -258,4 +258,4 @@ resolved.
- Blog post: [Getting started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
- User documentation: [Git Large File Storage (LFS)](../topics/git/lfs/_index.md)
-- [GitLab Git Large File Storage (LFS) Administration](../administration/lfs/index.md) for GitLab Self-Managed
+- [GitLab Git Large File Storage (LFS) Administration](../administration/lfs/_index.md) for GitLab Self-Managed
diff --git a/doc/development/workhorse/_index.md b/doc/development/workhorse/_index.md
index af9e683c25987844f8e4ca0979d15654d2893032..2a0d4c2d1ab37068c7bc10d3f847fbe967e3847e 100644
--- a/doc/development/workhorse/_index.md
+++ b/doc/development/workhorse/_index.md
@@ -34,13 +34,13 @@ When required, Workhorse makes modifications to HTTP headers which GitLab Rails
- For specific types of requests, especially those that are resource-intensive or require specialized handling
(for example, large file uploads), Workhorse takes a more active role.
Upon receiving directives from Rails, Workhorse executes specialized tasks such as directly
- interacting with [Gitaly](../../administration/gitaly/index.md) or offloading processing file uploads from Rails.
+ interacting with [Gitaly](../../administration/gitaly/_index.md) or offloading processing file uploads from Rails.
### Specialized task handling
- Workhorse is capable of intercepting certain requests based on Rails' responses and executing
predefined operations.
- This includes interacting with [Gitaly](../../administration/gitaly/index.md), managing large data
+ This includes interacting with [Gitaly](../../administration/gitaly/_index.md), managing large data
blobs, and altering request handling logic as required.
- A notable functionality is its ability to manage file uploads efficiently.
Workhorse can hijack the file upload process, perform necessary actions as dictated by Rails
diff --git a/doc/install/installation.md b/doc/install/installation.md
index dea946d4eef40c41e72811a3a7f6a2fa1aba12f8..5fe64885a425678dcce61ccf95769a36744bf1eb 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -762,7 +762,7 @@ sudo -u git -H editor config.toml
```
For more information about configuring Gitaly see
-[the Gitaly documentation](../administration/gitaly/index.md).
+[the Gitaly documentation](../administration/gitaly/_index.md).
### Install the service
diff --git a/doc/topics/git/clone.md b/doc/topics/git/clone.md
index cb008d1fe2f0e9c7bc2dba1a01b2e63403ceb306..a309cdd75a70793d3285d0ceda0d3bfdc255c0d2 100644
--- a/doc/topics/git/clone.md
+++ b/doc/topics/git/clone.md
@@ -234,7 +234,7 @@ Deeper integration between partial clone and sparse checkout is possible through
WARNING:
Partial clone using `sparse` filters is still experimental. It might be slow and significantly increase
-[Gitaly](../../administration/gitaly/index.md) resource utilization when cloning and fetching.
+[Gitaly](../../administration/gitaly/_index.md) resource utilization when cloning and fetching.
[Filter all blobs and use sparse-checkout](#filter-by-object-type) instead, because
[`git-sparse-checkout`](https://git-scm.com/docs/git-sparse-checkout) simplifies
this type of partial clone use and overcomes its limitations.
diff --git a/doc/topics/git/lfs/_index.md b/doc/topics/git/lfs/_index.md
index 91532c0785f6a58e3cac36da785d2fc80e805ad8..5668e5c5c77070942a916c6ecd8f33067f70b7af 100644
--- a/doc/topics/git/lfs/_index.md
+++ b/doc/topics/git/lfs/_index.md
@@ -70,7 +70,7 @@ GitLab enables Git LFS by default for both self-managed instances and GitLab.com
It offers both server settings and project-specific settings.
- To configure Git LFS on your instance, such as setting up remote object storage, see
- [GitLab Git Large File Storage (LFS) Administration](../../../administration/lfs/index.md).
+ [GitLab Git Large File Storage (LFS) Administration](../../../administration/lfs/_index.md).
- To configure Git LFS for a specific project:
1. In the root directory of your local copy of the repository, run `git lfs install`. This command
@@ -111,7 +111,7 @@ authentication.
By default, Git LFS operations occur over HTTPS, even when Git communicates with your repository over SSH.
In GitLab 17.2, [pure SSH support for LFS](https://gitlab.com/groups/gitlab-org/-/epics/11872) was introduced.
-For information on how to enable this feature, see [Pure SSH transfer protocol](../../../administration/lfs/index.md#pure-ssh-transfer-protocol).
+For information on how to enable this feature, see [Pure SSH transfer protocol](../../../administration/lfs/_index.md#pure-ssh-transfer-protocol).
To fetch new LFS objects for a repository you have already cloned, run this command:
@@ -152,6 +152,6 @@ the total size of your repository, see
- Blog post: [Getting started with Git LFS](https://about.gitlab.com/blog/2017/01/30/getting-started-with-git-lfs-tutorial/)
- [Git LFS with Git](../../git/file_management.md#git-lfs)
- [Git LFS developer information](../../../development/lfs.md)
-- [GitLab Git Large File Storage (LFS) Administration](../../../administration/lfs/index.md) for self-managed instances
+- [GitLab Git Large File Storage (LFS) Administration](../../../administration/lfs/_index.md) for self-managed instances
- [Troubleshooting Git LFS](troubleshooting.md)
- [The `.gitattributes` file](../../../user/project/repository/files/git_attributes.md)
diff --git a/doc/topics/git/lfs/troubleshooting.md b/doc/topics/git/lfs/troubleshooting.md
index 7e5db589b6305681dfb60f761a9f5bc1c7ec452f..8156fa04ce5277660dc75799094a190b5d38bfc1 100644
--- a/doc/topics/git/lfs/troubleshooting.md
+++ b/doc/topics/git/lfs/troubleshooting.md
@@ -42,7 +42,7 @@ These problems can cause `501` errors:
- Git LFS support is not enabled on the GitLab server. Check with your GitLab
administrator why Git LFS is not enabled on the server. See
- [LFS administration documentation](../../../administration/lfs/index.md) for instructions
+ [LFS administration documentation](../../../administration/lfs/_index.md) for instructions
on how to enable Git LFS support.
- The Git LFS client version is not supported by GitLab server. You should:
diff --git a/doc/update/zero_downtime.md b/doc/update/zero_downtime.md
index 3624ce5f0364a38f52d400ec9768c277132fd741..9bbd9cb52cdeda5a85340a7187d4f102226f763e 100644
--- a/doc/update/zero_downtime.md
+++ b/doc/update/zero_downtime.md
@@ -110,7 +110,7 @@ Run through the following steps sequentially on each component's node to perform
### Gitaly
-[Gitaly](../administration/gitaly/index.md) follows the same core process when it comes to upgrading but with a key difference
+[Gitaly](../administration/gitaly/_index.md) follows the same core process when it comes to upgrading but with a key difference
that the Gitaly process itself is not restarted as it has a built-in process to gracefully reload
at the earliest opportunity. Note that any other component will still need to be restarted.
diff --git a/doc/user/project/issues/design_management.md b/doc/user/project/issues/design_management.md
index 2439975bf26bc15bb42165ae36bc207071efa4a5..f3cfaa8b56978d37112a3dca7a6a7863edbf1f90 100644
--- a/doc/user/project/issues/design_management.md
+++ b/doc/user/project/issues/design_management.md
@@ -25,7 +25,7 @@ For a video overview, see [Design Management](https://www.youtube.com/watch?v=CC
- [Git Large File Storage (LFS)](../../../topics/git/lfs/_index.md) must be enabled:
- On GitLab.com, LFS is already enabled.
- On self-managed instances, a GitLab administrator must
- [enable LFS globally](../../../administration/lfs/index.md).
+ [enable LFS globally](../../../administration/lfs/_index.md).
- On both GitLab.com and self-managed instances, LFS must be
[enabled for the project itself](../settings/index.md#configure-project-features-and-permissions).
If enabled globally, LFS is enabled by default for all projects. If you have