Use relative URLs in development docs

This is part of https://gitlab.com/gitlab-org/gitlab-ce/issues/61945

doc/development/code_review.md

@@ -27,7 +27,7 @@ Depending on the areas your merge request touches, it must be **approved** by on
 or more [maintainers](https://about.gitlab.com/handbook/engineering/workflow/code-review/#maintainer):
 
 For approvals, we use the approval functionality found in the merge request
-widget. Reviewers can add their approval by [approving additionally](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html#adding-or-removing-an-approval).
+widget. Reviewers can add their approval by [approving additionally](../user/project/merge_requests/merge_request_approvals.md#adding-or-removing-an-approval).
 
 Getting your merge request **merged** also requires a maintainer. If it requires
 more than one approval, the last maintainer to review and approve it will also merge it.
@@ -43,7 +43,7 @@ It picks reviewers and maintainers from the list at the
 [engineering projects](https://about.gitlab.com/handbook/engineering/projects/)
 page, with these behaviours:
 
-1. It will not pick people whose [GitLab status](../user/profile/#current-status)
+1. It will not pick people whose [GitLab status](../user/profile/index.md#current-status)
    contains the string 'OOO'.
 2. [Trainee maintainers](https://about.gitlab.com/handbook/engineering/workflow/code-review/#trainee-maintainer)
    are three times as likely to be picked as other reviewers.
@@ -152,7 +152,7 @@ required approvers.
 
 Maintainers must check before merging if the merge request is introducing new
 vulnerabilities, by inspecting the list in the Merge Request [Security
-Widget](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports-ultimate).
+Widget](../user/project/merge_requests/index.md#security-reports-ultimate).
 When in doubt, a [Security Engineer][team] can be involved. The list of detected
 vulnerabilities must be either empty or containing:
 
@@ -286,7 +286,7 @@ experience, refactors the existing code). Then:
   author has already set this option or if the merge request clearly contains a
   messy commit history that is intended to be squashed.
 
-[squash-and-merge]: https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#squash-and-merge
+[squash-and-merge]: ../user/project/merge_requests/squash_and_merge.md#squash-and-merge
 
 ### The right balance
 
@@ -319,7 +319,7 @@ reviewee.
 GitLab is used in a lot of places. Many users use
 our [Omnibus packages](https://about.gitlab.com/installation/), but some use
 the [Docker images](https://docs.gitlab.com/omnibus/docker/), some are
-[installed from source](https://docs.gitlab.com/ce/install/installation.html),
+[installed from source](../install/installation.md),
 and there are other installation methods available. GitLab.com itself is a large
 Enterprise Edition instance. This has some implications:
 

doc/development/distributed_tracing.md

@@ -34,7 +34,7 @@ GITLAB_TRACING=opentracing://<driver>?<param_name>=<param_value>&<param_name_2>=
 In this example, we have the following hypothetical values:
 
 - `driver`: the driver. [GitLab supports
-  `jaeger`](https://docs.gitlab.com/ee/user/project/operations/tracing.html). In future, other
+  `jaeger`](../user/project/operations/tracing.md). In future, other
   tracing implementations may also be supported.
 - `param_name`, `param_value`: these are driver specific configuration values. Configuration
   parameters for Jaeger are documented [further on in this

doc/development/documentation/feature-change-workflow.md

@@ -86,7 +86,7 @@ Everyone is encouraged to draft the requirements in the issue, but a product man
 do the following:
 
 - When the issue is assigned a release milestone, review and update the Documentation details.
-- By the kickoff, finalizie the Documentation details.
+- By the kickoff, finalize the Documentation details.
 
 ### Developer and maintainer roles
 
@@ -117,7 +117,7 @@ Follow the process below unless otherwise agreed with the product manager and te
 
 #### Reviews and merging
 
-All reviewers can help ensure accuracy, clarity, completeness, and adherence to the plans in the issue, as well as the [Documentation Guidelines](https://docs.gitlab.com/ee/development/documentation/) and [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide.html).
+All reviewers can help ensure accuracy, clarity, completeness, and adherence to the plans in the issue, as well as the [Documentation Guidelines](index.md) and [Style Guide](styleguide.md).
 
 - **Prior to merging**, documentation changes committed by the developer must be reviewed by:
 
@@ -136,7 +136,7 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
    1. **The maintainer** who is assigned to merge the MR, to verify clarity, completeness, and quality, to the best of their ability.
 
 - Upon merging, if a technical writer review has not been performed and there is not yet a linked issue for a follow-up review, the maintainer should [create an issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review), link it from the MR, and
-  mention the original MR author in the new issue. Alternatively, the mainitainer can ask the MR author to create and link this issue before the MR is merged.
+  mention the original MR author in the new issue. Alternatively, the maintainer can ask the MR author to create and link this issue before the MR is merged.
 
 - After merging, documentation changes are reviewed by:
 
@@ -157,14 +157,14 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to
 #### Collaboration
 
 By default, the developer will work on documentation changes independently, but
-the developer, PM, or technicial writer can propose a broader collaboration for
+the developer, PM, or technical writer can propose a broader collaboration for
 any given issue.
 
 Additionally, technical writers are available for questions at any time.
 
 #### Review
 
-- Techncial writers provide non-blocking reviews of all documentation changes,
+- Technical writers provide non-blocking reviews of all documentation changes,
   before or after the change is merged. However, if the docs are ready in the MR while
   there's time before the freeze, the technical writer's review can commence early, on request.
 - The technical writer will confirm that the doc is clear, grammatically correct,
@@ -173,7 +173,7 @@ Additionally, technical writers are available for questions at any time.
   the developer and code reviewer should have already made a good-faith effort to ensure:
   - Clarity.
   - Adherence to the plans and goals in the issue.
-  - Location (make sure the docs are in the correct directorkes and has the correct name).
+  - Location (make sure the docs are in the correct directories and has the correct name).
   - Syntax, typos, and broken links.
   - Improvements to the content.
   - Accordance with the [Documentation Style Guide](styleguide.md), and [Structure and Template](structure.md) doc.

doc/development/documentation/index.md

@@ -466,7 +466,7 @@ If you want to know the in-depth details, here's what's really happening:
 The following GitLab features are used among others:
 
 - [Manual actions](../../ci/yaml/README.md#whenmanual)
-- [Multi project pipelines](https://docs.gitlab.com/ee/ci/multi_project_pipeline_graphs.html)
+- [Multi project pipelines](../../ci/multi_project_pipeline_graphs.md)
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/README.md#artifacts)
 - [Specific Runner](../../ci/runners/README.md#locking-a-specific-runner-from-being-enabled-for-other-projects)

doc/development/documentation/structure.md

@@ -77,8 +77,8 @@ for use (e.g. variations on the main use case), but if that's not applicable, th
 Examples of use cases on feature pages:
 - CE and EE: [Issues](../../user/project/issues/index.md#use-cases)
 - CE and EE: [Merge Requests](../../user/project/merge_requests/index.md)
-- EE-only: [Geo](https://docs.gitlab.com/ee/administration/geo/replication/index.html)
-- EE-only: [Jenkins integration](https://docs.gitlab.com/ee/integration/jenkins.html)
+- EE-only: [Geo](../../administration/geo/replication/index.md)
+- EE-only: [Jenkins integration](../../integration/jenkins.md)
 
 ## Requirements
 
@@ -121,8 +121,8 @@ but commented out to help encourage others to add to it in the future. -->
 
 Notes:
 
-- (1): Apply the [tier badges](https://docs.gitlab.com/ee/development/documentation/styleguide.html#product-badges) accordingly
-- (2): Apply the correct format for the [GitLab version introducing the feature](https://docs.gitlab.com/ee/development/documentation/styleguide.html#gitlab-versions-and-tiers)
+- (1): Apply the [tier badges](styleguide.md#product-badges) accordingly
+- (2): Apply the correct format for the [GitLab version introducing the feature](styleguide.md#gitlab-versions-and-tiers)
 ```
 
 ## Help and feedback section

doc/development/ee_features.md

@@ -933,7 +933,7 @@ export default {
 ```
 
 #### For JS code that is EE only, like props, computed properties, methods, etc, we will keep the current approach
- - Since we [can't async load a mixin](https://github.com/vuejs/vue-loader/issues/418#issuecomment-254032223) we will use the [`ee_else_ce`](https://docs.gitlab.com/ee/development/ee_features.html#javascript-code-in-assetsjavascripts) alias we already have for webpack.
+ - Since we [can't async load a mixin](https://github.com/vuejs/vue-loader/issues/418#issuecomment-254032223) we will use the [`ee_else_ce`](../development/ee_features.md#javascript-code-in-assetsjavascripts) alias we already have for webpack.
   - This means all the EE specific props, computed properties, methods, etc that are EE only should be in a mixin in the `ee/` folder and we need to create a CE counterpart of the mixin
 
 ##### Example:
@@ -960,7 +960,7 @@ import mixin from 'ee_else_ce/path/mixin';
 ### Non Vue Files
 For regular JS files, the approach is similar.
 
-1. We will keep using the [`ee_else_ce`](https://docs.gitlab.com/ee/development/ee_features.html#javascript-code-in-assetsjavascripts) helper, this means that EE only code should be inside the `ee/` folder.
+1. We will keep using the [`ee_else_ce`](../development/ee_features.md#javascript-code-in-assetsjavascripts) helper, this means that EE only code should be inside the `ee/` folder.
   1. An EE file should be created with the EE only code, and it should extend the CE counterpart.
   1. For code inside functions that can't be extended, the code should be moved into a new file and we should use `ee_else_ce` helper:
 

doc/development/elasticsearch.md

@@ -2,7 +2,7 @@
 
 This area is to maintain a compendium of useful information when working with elasticsearch.
 
-Information on how to enable ElasticSearch and perform the initial indexing is kept in https://docs.gitlab.com/ee/integration/elasticsearch.html#enabling-elasticsearch
+Information on how to enable ElasticSearch and perform the initial indexing is kept in ../integration/elasticsearch.md#enabling-elasticsearch
 
 ## Initial installation on OS X
 
@@ -16,7 +16,7 @@ and use `docker stop elastic56` and `docker start elastic56` to stop/start it.
 
 ### Installing on the host
 
-We currently only support Elasticsearch [5.6 to 6.x](https://docs.gitlab.com/ee/integration/elasticsearch.html#requirements)
+We currently only support Elasticsearch [5.6 to 6.x](../integration/elasticsearch.md#version-requirements)
 
 Version 5.6 is available on homebrew and is the recommended version to use in order to test compatibility.
 
@@ -43,7 +43,7 @@ this adds `gitlab-elasticsearch-indexer` to `$GOPATH/bin`, please make sure that
 - `gitlab:elastic:test:index_size`: Tells you how much space the current index is using, as well as how many documents are in the index.
 - `gitlab:elastic:test:index_size_change`: Outputs index size, reindexes, and outputs index size again. Useful when testing improvements to indexing size.
 
-Additionally, if you need large repos or multiple forks for testing, please consider [following these instructions](https://docs.gitlab.com/ee/development/rake_tasks.html#extra-project-seed-options)
+Additionally, if you need large repos or multiple forks for testing, please consider [following these instructions](rake_tasks.md#extra-project-seed-options)
 
 ## How does it work?
 

doc/development/feature_flags.md

@@ -28,7 +28,7 @@ the time, you should execute `/chatops run feature set my_feature_flag 50`.
 
 This document only covers feature flags used in the development of GitLab 
 itself. Feature flags in deployed user applications can be found at 
-[Feature Flags](https://docs.gitlab.com/ee/user/project/operations/feature_flags.html)
+[Feature Flags](../user/project/operations/feature_flags.md)
 
 ## Developing with feature flags
 
@@ -111,7 +111,7 @@ Whenever a feature flag is present, make sure to test _both_ states of the
 feature flag.
 
 See the
-[testing guide](testing_guide/best_practices.html#feature-flags-in-tests)
+[testing guide](testing_guide/best_practices.md#feature-flags-in-tests)
 for information and examples on how to stub feature flags in tests.
 
 ## Enabling a feature flag (in development)

doc/development/geo.md

@@ -90,7 +90,7 @@ projects that need updating. Those projects can be:
   timestamp that is more recent than the `last_repository_successful_sync_at`
   timestamp in the `Geo::ProjectRegistry` model.
 - Manual: The admin can manually flag a repository to resync in the
-  [Geo admin panel](https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html).
+  [Geo admin panel](../user/admin_area/geo_nodes.md).
 
 When we fail to fetch a repository on the secondary `RETRIES_BEFORE_REDOWNLOAD`
 times, Geo does a so-called _redownload_. It will do a clean clone
@@ -299,7 +299,7 @@ basically hashes all Git refs together and stores that hash in the
 The **secondary** node does the same to calculate the hash of its
 clone, and compares the hash with the value the **primary** node
 calculated. If there is a mismatch, Geo will mark this as a mismatch
-and the administrator can see this in the [Geo admin panel](https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html).
+and the administrator can see this in the [Geo admin panel](../user/admin_area/geo_nodes.md).
 
 ## Glossary
 

doc/development/go_guide/index.md

@@ -40,7 +40,7 @@ of possible security breaches in our code:
 - SQL injections
 
 Remember to run
-[SAST](https://docs.gitlab.com/ee/user/application_security/sast/index)
+[SAST](../../user/application_security/sast/index.md)
 **[ULTIMATE]** on your project (or at least the [gosec
 analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)),
 and to follow our [Security
@@ -94,9 +94,9 @@ become available, you will be able to share job templates like this
 Dependencies should be kept to the minimum. The introduction of a new
 dependency should be argued in the merge request, as per our [Approval
 Guidelines](../code_review.md#approval-guidelines). Both [License
-Management](https://docs.gitlab.com/ee/user/project/merge_requests/license_management.html)
+Management](../../user/project/merge_requests/license_management.md)
 **[ULTIMATE]** and [Dependency
-Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/index)
+Scanning](../../user/application_security/dependency_scanning/index.md)
 **[ULTIMATE]** should be activated on all projects to ensure new dependencies
 security status and license compatibility.
 

doc/development/i18n/merging_translations.md

@@ -32,7 +32,7 @@ clicking `Pause sync` on the [Crowdin integration settings
 page](https://translate.gitlab.com/project/gitlab-ee/settings#integration).
 
 When all failures are resolved, the translations need to be double
-checked once more as discussed in [confidential issue](https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html) `https://gitlab.com/gitlab-org/gitlab-ce/issues/37850`.
+checked once more as discussed in [confidential issue](../../user/project/issues/confidential_issues.md) `https://gitlab.com/gitlab-org/gitlab-ce/issues/37850`.
 
 ## Merging translations
 

doc/development/import_export.md

@@ -27,7 +27,7 @@ Read through the current performance problems using the Import/Export below.
 
 ### OOM errors
 
-Out of memory (OOM) errors are normally caused by the [Sidekiq Memory Killer](https://docs.gitlab.com/ee/administration/operations/sidekiq_memory_killer.html):
+Out of memory (OOM) errors are normally caused by the [Sidekiq Memory Killer](../administration/operations/sidekiq_memory_killer.md):
 
 ```bash
 SIDEKIQ_MEMORY_KILLER_MAX_RSS = 2GB in GitLab.com

doc/development/licensed_feature_availability.md

@@ -7,8 +7,8 @@ on-premise or GitLab.com plans and features.
 ## Restricting features scoped by namespaces or projects
 
 GitLab.com plans are persisted on user groups and namespaces, therefore, if you're adding a
-feature such as [Related issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) or 
-[Service desk](https://docs.gitlab.com/ee/user/project/service_desk.html), 
+feature such as [Related issues](../user/project/issues/related_issues.md) or 
+[Service desk](../user/project/service_desk.md), 
 it should be restricted on namespace scope.
 
 1. Add the feature symbol on `EES_FEATURES`, `EEP_FEATURES` or `EEU_FEATURES` constants in 
@@ -22,8 +22,8 @@ project.feature_available?(:feature_symbol)
 
 ## Restricting global features (instance)
 
-However, for features such as [Geo](https://docs.gitlab.com/ee/administration/geo/replication/index.html) and 
-[Load balancing](https://docs.gitlab.com/ee/administration/database_load_balancing.html), which cannot be restricted 
+However, for features such as [Geo](../administration/geo/replication/index.md) and 
+[Load balancing](../administration/database_load_balancing.md), which cannot be restricted 
 to only a subset of projects or namespaces, the check will be made directly in 
 the instance license.
 

doc/development/new_fe_guide/development/components.md

@@ -17,5 +17,5 @@ D3 is very popular across many projects outside of GitLab:
 
 Within GitLab, D3 has been used for the following notable features
 
-- [Prometheus graphs](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html)
+- [Prometheus graphs](../../../user/project/integrations/prometheus.md)
 - Contribution calendars

doc/development/new_fe_guide/tips.md

@@ -10,16 +10,16 @@ yarn clean
 
 ## Creating feature flags in development
 
-The process for creating a feature flag is the same as [enabling a feature flag in development](https://docs.gitlab.com/ee/development/feature_flags.html#enabling-a-feature-flag-in-development).
+The process for creating a feature flag is the same as [enabling a feature flag in development](../feature_flags.md#enabling-a-feature-flag-in-development).
 
 Your feature flag can now be:
 
-- [made available to the frontend](https://docs.gitlab.com/ee/development/feature_flags.html#frontend) via the `gon`
-- queried in [tests](https://docs.gitlab.com/ee/development/feature_flags.html#specs)
+- [made available to the frontend](../feature_flags.md#frontend) via the `gon`
+- queried in [tests](../feature_flags.md#specs)
 - queried in HAML templates and ruby files via the `Feature.enabled?(:my_shiny_new_feature_flag)` method
 
 ### More on feature flags
 
-- [Deleting a feature flag](https://docs.gitlab.com/ee/api/features.html#delete-a-feature)
-- [Manage feature flags](https://docs.gitlab.com/ee/development/feature_flags.html)
-- [Feature flags API](https://docs.gitlab.com/ee/api/features.html)
+- [Deleting a feature flag](../../api/features.md#delete-a-feature)
+- [Manage feature flags](../feature_flags.md)
+- [Feature flags API](../../api/features.md)

doc/development/packages.md

 # Packages **[PREMIUM]**
 
-This document will guide you through adding another [package management system](https://docs.gitlab.com/ee/administration/packages.html) support to GitLab.
+This document will guide you through adding another [package management system](../administration/packages.md) support to GitLab.
 
-See already supported package types in [Packages documentation](https://docs.gitlab.com/ee/administration/packages.html)
+See already supported package types in [Packages documentation](../administration/packages.md)
 
 Since GitLab packages' UI is pretty generic, it is possible to add new
 package system support by solely backend changes. This guide is superficial and does 
@@ -46,7 +46,7 @@ Group-level and instance-level endpoints are good to have but are optional.
 
 NOTE: **Note:**
 To avoid name conflict for instance-level endpoints we use 
-[the package naming convention](https://docs.gitlab.com/ee/user/project/packages/npm_registry.html#package-naming-convention)
+[the package naming convention](../user/project/packages/npm_registry.md#package-naming-convention)
 
 ## Configuration
 

doc/development/rake_tasks.md

@@ -31,7 +31,7 @@ project.
 #### Seeding issues for Insights charts **[ULTIMATE]**
 
 You can seed issues specifically for working with the
-[Insights charts](https://docs.gitlab.com/ee/user/group/insights/index.html) with the
+[Insights charts](../user/group/insights/index.md) with the
 `gitlab:seed:insights:issues` task:
 
 ```shell

doc/development/rolling_out_changes_using_feature_flags.md

@@ -102,7 +102,7 @@ GitLab's feature library (using
 [Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
 Flags](feature_flags.md) guide) supports rolling out changes to a percentage of
 users. This in turn can be controlled using [GitLab
-chatops](https://docs.gitlab.com/ee/ci/chatops/).
+chatops](../ci/chatops/README.md).
 
 For an up to date list of feature flag commands please see [the source
 code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb).

doc/development/testing_guide/review_apps.md

@@ -113,7 +113,7 @@ You can also manually start the `review-qa-all`: it runs the full QA suite.
 On every [pipeline][gitlab-pipeline] in the `qa` stage, the
 `review-performance` job is automatically started: this job does basic
 browser performance testing using a
-[Sitespeed.io Container](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html).
+[Sitespeed.io Container](../../user/project/merge_requests/browser_performance_testing.md).
 
 ## How to:
 
@@ -203,7 +203,7 @@ find a way to limit it to only us.**
 [automated_cleanup.rb]: https://gitlab.com/gitlab-org/gitlab-ee/blob/master/scripts/review_apps/automated_cleanup.rb
 [Auto-DevOps.gitlab-ci.yml]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml
 [gitlab-ci-yml]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/.gitlab-ci.yml
-[gitlab-k8s-integration]: https://docs.gitlab.com/ee/user/project/clusters/index.html
+[gitlab-k8s-integration]: ../../user/project/clusters/index.md
 [password-bug]: https://gitlab.com/gitlab-org/gitlab-ce/issues/53621
 
 ---

doc/university/support/README.md

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