Update links to use .md suffix, not .html

Internal links should use a .md suffix, not a .html suffix. This
commit corrects links across several files.

doc/ci/examples/end_to_end_testing_webdriverio/index.md

@@ -147,7 +147,7 @@ need to do for this:
 
 For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages)
 `confidence-check` that is executed _after_ the stage that deploys the review app. It uses the `node:latest` [Docker
-image](../../docker/using_docker_images.html). However, WebdriverIO fires up actual browsers
+image](../../docker/using_docker_images.md). However, WebdriverIO fires up actual browsers
 to interact with your application, so we need to install and run them.
 Furthermore, WebdriverIO uses Selenium as a common interface to control different browsers,
 so we need to install and run Selenium as well. Luckily, the Selenium project provides the Docker images
@@ -187,7 +187,7 @@ option as an argument to `npm run confidence-check` on the command line.
 However, we still need to tell WebdriverIO which browser is available for it to use.
 
 [GitLab CI/CD makes
-a number of variables available](../../variables/README.html#predefined-environment-variables)
+a number of variables available](../../variables/README.md#predefined-environment-variables)
 with information about the current CI job. We can use this information to dynamically set
 up our WebdriverIO configuration according to the job that is running. More specifically, we can
 tell WebdriverIO what browser to execute the test on depending on the name of the currently running

doc/ci/jenkins/index.md

@@ -62,7 +62,7 @@ rspec:
 
 Artifacts may work a bit differently than you've used them with Jenkins. In GitLab, any job can define
 a set of artifacts to be saved by using the `artifacts:` keyword. This can be configured to point to a file
-or set of files that can then be persisted from job to job. Read more on our detailed [artifacts documentation](../../user/project/pipelines/job_artifacts.html)
+or set of files that can then be persisted from job to job. Read more on our detailed [artifacts documentation](../../user/project/pipelines/job_artifacts.md)
 
 ```yaml
 pdf:
@@ -129,7 +129,7 @@ stages:
   - test
   - deploy
   - after_pipeline
-```  
+```
 
 Setting a step to be performed before and after any job can be done via the [`before_script` and `after_script` keywords](../yaml/README.md#before_script-and-after_script).
 

doc/ci/yaml/README.md

@@ -736,7 +736,7 @@ This means the `only:changes` policy is useful for pipelines where:
 - `$CI_PIPELINE_SOURCE == 'external_pull_request_event'`
 
 If there is no Git push event, such as for pipelines with
-[sources other than the three above](../variables/predefined_variables.html#variables-reference),
+[sources other than the three above](../variables/predefined_variables.md#variables-reference),
 `changes` cannot determine if a given file is new or old, and will always
 return true.
 

doc/integration/github.md

@@ -59,7 +59,7 @@ Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
 
    **Replace `https://github.example.com/` with your GitHub URL.**
 
-1. Save the file and [reconfigure](../administration/restart_gitlab.html#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
+1. Save the file and [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab for the changes to take effect.
 
 ---
 
@@ -86,7 +86,7 @@ Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
 
    **Replace `https://github.example.com/` with your GitHub URL.**
 
-1. Save the file and [restart](../administration/restart_gitlab.html#installations-from-source) GitLab for the changes to take effect.
+1. Save the file and [restart](../administration/restart_gitlab.md#installations-from-source) GitLab for the changes to take effect.
 
 ---
 

doc/integration/saml.md

@@ -549,7 +549,7 @@ GitLab will sign the request with the provided private key. GitLab will include
 
 If you need to troubleshoot, [a complete GitLab+SAML testing environment using Docker compose](https://gitlab.com/gitlab-com/support/toolbox/replication/tree/master/compose_files) is available.
 
-If you only need a SAML provider for testing, a [quick start guide to start a Docker container](../administration/troubleshooting/test_environments.html#saml) with a plug and play SAML 2.0 Identity Provider (IdP) is available.
+If you only need a SAML provider for testing, a [quick start guide to start a Docker container](../administration/troubleshooting/test_environments.md#saml) with a plug and play SAML 2.0 Identity Provider (IdP) is available.
 
 ### 500 error after login
 

doc/user/admin_area/activating_deactivating_users.md

@@ -38,7 +38,7 @@ Please note that for the deactivation option to be visible to an admin, the user
 - Must be currently active.
 - Should not have any activity in the last 180 days.
 
-Users can also be deactivated using the [GitLab API](../../api/users.html#deactivate-user).
+Users can also be deactivated using the [GitLab API](../../api/users.md#deactivate-user).
 
 NOTE: **Note:**
 A deactivated user does not consume a [seat](../../subscriptions/index.md#managing-subscriptions).
@@ -56,7 +56,7 @@ To do this:
 1. Select a user.
 1. Under the **Account** tab, click **Activate user**.
 
-Users can also be activated using the [GitLab API](../../api/users.html#activate-user).
+Users can also be activated using the [GitLab API](../../api/users.md#activate-user).
 
 NOTE: **Note:**
 Activating a user will change the user's state to active and it consumes a

doc/user/admin_area/blocking_unblocking_users.md

@@ -27,7 +27,7 @@ A blocked user:
 
 Personal projects, and group and user history of the blocked user will be left intact.
 
-Users can also be blocked using the [GitLab API](../../api/users.html#block-user).
+Users can also be blocked using the [GitLab API](../../api/users.md#block-user).
 
 NOTE: **Note:**
 A blocked user does not consume a [seat](../../subscriptions/index.md#managing-subscriptions).
@@ -41,7 +41,7 @@ A blocked user can be unblocked from the Admin Area. To do this:
 1. Select a user.
 1. Under the **Account** tab, click **Unblock user**.
 
-Users can also be unblocked using the [GitLab API](../../api/users.html#unblock-user).
+Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user).
 
 NOTE: **Note:**
 Unblocking a user will change the user's state to active and it consumes a

doc/user/permissions.md

@@ -425,7 +425,7 @@ for details about the pipelines security model.
 ## LDAP users permissions
 
 Since GitLab 8.15, LDAP user permissions can now be manually overridden by an admin user.
-Read through the documentation on [LDAP users permissions](../administration/auth/how_to_configure_ldap_gitlab_ee/index.html) to learn more.
+Read through the documentation on [LDAP users permissions](../administration/auth/how_to_configure_ldap_gitlab_ee/index.md) to learn more.
 
 ## Project aliases