Make links relative

doc/install/kubernetes/gitlab_chart.md

@@ -8,7 +8,7 @@ The `gitlab` Helm chart deploys just GitLab into your Kubernetes cluster, and of
 This chart includes the following:
 
 - Deployment using the [gitlab-ce](https://hub.docker.com/r/gitlab/gitlab-ce) or [gitlab-ee](https://hub.docker.com/r/gitlab/gitlab-ee) container image
-- ConfigMap containing the `gitlab.rb` contents that configure [Omnibus GitLab](https://docs.gitlab.com/omnibus/settings/configuration.html#configuration-options)
+- ConfigMap containing the `gitlab.rb` contents that configure [Omnibus GitLab](../../../omnibus/settings/configuration.html#configuration-options)
 - Persistent Volume Claims for Data, Config, Logs, and Registry Storage
 - A Kubernetes service
 - Optional Redis deployment using the [Redis Chart](https://github.com/kubernetes/charts/tree/master/stable/redis) (defaults to enabled)
@@ -87,7 +87,7 @@ used by default in the chart, will be supported by a chart install.
 ### Custom Omnibus GitLab configuration
 
 In addition to the configuration options provided for GitLab in the Helm Chart, you can also pass any custom configuration
-that is valid for the [Omnibus GitLab Configuration](https://docs.gitlab.com/omnibus/settings/configuration.html).
+that is valid for the [Omnibus GitLab Configuration](../../../omnibus/settings/configuration.html).
 
 The setting to pass these values in is `omnibusConfigRuby`. It accepts any valid
 Ruby code that could used in the Omnibus `/etc/gitlab/gitlab.rb` file. In
@@ -286,7 +286,7 @@ redis:
 
 By default, the GitLab container will not be able to send email from your cluster.
 In order to send email, you should configure SMTP settings in the
-`omnibusConfigRuby` section, as per the [GitLab Omnibus documentation](https://docs.gitlab.com/omnibus/settings/smtp.html).
+`omnibusConfigRuby` section, as per the [GitLab Omnibus documentation](../../../omnibus/settings/smtp.html).
 
 >**Note:**
 Some cloud providers restrict emails being sent out on SMTP, so you will have
@@ -318,7 +318,7 @@ omnibusConfigRuby: |
 To setup HTTPS access to your GitLab server, first you need to configure the
 chart to use the [ingress](#ingress-routing).
 
-GitLab's config should be updated to support [proxied SSL](https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl).
+GitLab's config should be updated to support [proxied SSL](../../../omnibus/settings/nginx.html#supporting-proxied-ssl).
 
 In addition to having a Ingress Controller deployed and the basic ingress
 settings configured, you will also need to specify in the ingress settings

doc/install/kubernetes/gitlab_omnibus.md

@@ -14,7 +14,7 @@ This chart provides an easy way to get started with GitLab, provisioning an inst
 
 The deployment includes:
 
-- A [GitLab Omnibus](https://docs.gitlab.com/omnibus/) Pod, including Mattermost, Container Registry, and Prometheus
+- A [GitLab Omnibus](../../../omnibus/) Pod, including Mattermost, Container Registry, and Prometheus
 - An auto-scaling [GitLab Runner](https://docs.gitlab.com/runner/) using the Kubernetes executor
 - [Redis](https://github.com/kubernetes/charts/tree/master/stable/redis)
 - [PostgreSQL](https://github.com/kubernetes/charts/tree/master/stable/postgresql)
@@ -23,7 +23,7 @@ The deployment includes:
 
 ### Limitations
 
-* This chart is suited for small to medium size deployments, because [High Availability](https://docs.gitlab.com/ee/administration/high_availability/) and [Geo](https://docs.gitlab.com/ee/gitlab-geo/README.html) will not be supported.
+* This chart is suited for small to medium size deployments, because [High Availability](../../administration/high_availability/) and [Geo](../../gitlab-geo/README.html) will not be supported.
 * It is in beta. Additional features to support production deployments, like backups, are [in development](https://gitlab.com/charts/charts.gitlab.io/issues/68). Once completed, this chart will be generally available.
 * A new generation of [cloud native charts](index.md#upcoming-cloud-native-helm-charts) is in development, and will eventually deprecate these. Due to the difficulty in supporting upgrades to the new architecture, migrating will require exporting data out of this instance and importing it into the new deployment. We do not expect these to be production ready before the second half of 2018.
 
@@ -40,7 +40,7 @@ For more information on available GitLab Helm Charts, please see our [overview](
 
 ### Networking Prerequisites
 
-This chart configures a GitLab server and Kubernetes cluster which can support dynamic [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/index.html), as well as services like the integrated [Container Registry](https://docs.gitlab.com/ee/user/project/container_registry.html) and [Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/).
+This chart configures a GitLab server and Kubernetes cluster which can support dynamic [Review Apps](../../ci/review_apps/index.html), as well as services like the integrated [Container Registry](../../user/project/container_registry.html) and [Mattermost](../../../omnibus/gitlab-mattermost/).
 
 To support the GitLab services and dynamic environments, a wildcard DNS entry is required which resolves to the [Load Balancer](#load-balancer-ip) or [External IP](#external-ip). Configuration of the DNS entry will depend upon the DNS service being used.
 
@@ -71,7 +71,7 @@ For most installations, only two parameters are required:
 Other common configuration options:
 - `baseIP`: the desired [external IP address](#external-ip-recommended)
 - `gitlab`: Choose the [desired edition](https://about.gitlab.com/products), either `ee` or `ce`. `ce` is the default.
-- `gitlabEELicense`: For Enterprise Edition, the [license](https://docs.gitlab.com/ee/user/admin_area/license.html) can be installed directly via the Chart
+- `gitlabEELicense`: For Enterprise Edition, the [license](../../user/admin_area/license.html) can be installed directly via the Chart
 - `provider`: Optimizes the deployment for a cloud provider. The default is `gke` for [Google Container Engine](https://cloud.google.com/container-engine/), with `acs` also supported for the [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/).
 
 For additional configuration options, consult the [values.yaml](https://gitlab.com/charts/charts.gitlab.io/blob/master/charts/gitlab-omnibus/values.yaml).

doc/install/kubernetes/gitlab_runner_chart.md

@@ -7,7 +7,7 @@ Kubernetes cluster.
 
 This chart configures the Runner to:
 
-- Run using the GitLab Runner [Kubernetes executor](https://docs.gitlab.com/runner/install/kubernetes.html)
+- Run using the GitLab Runner [Kubernetes executor](../../../runner/install/kubernetes.html)
 - For each new job it receives from [GitLab CI](https://about.gitlab.com/features/gitlab-ci-cd/), it will provision a
   new pod within the specified namespace to run it.
 
@@ -118,7 +118,7 @@ runners:
 
 ### Controlling maximum Runner concurrency
 
-A single GitLab Runner deployed on Kubernetes is able to execute multiple jobs in parallel by automatically starting additional Runner pods. The [`concurrent` setting](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-global-section) controls the maximum number of pods allowed at a single time, and defaults to `10`.
+A single GitLab Runner deployed on Kubernetes is able to execute multiple jobs in parallel by automatically starting additional Runner pods. The [`concurrent` setting](../../../runner/configuration/advanced-configuration.html#the-global-section) controls the maximum number of pods allowed at a single time, and defaults to `10`.
 
 ```yaml
 ## Configure the maximum number of concurrent jobs
@@ -130,7 +130,7 @@ concurrent: 10
 ### Running Docker-in-Docker containers with GitLab Runners
 
 See [Running Privileged Containers for the Runners](#running-privileged-containers-for-the-runners) for how to enable it,
-and the [GitLab CI Runner documentation](https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-in-your-builds) on running dind.
+and the [GitLab CI Runner documentation](../../../runner/executors/kubernetes.html#using-docker-in-your-builds) on running dind.
 
 ### Running privileged containers for the Runners
 
@@ -138,7 +138,7 @@ You can tell the GitLab Runner to run using privileged containers. You may need
 this enabled if you need to use the Docker executable within your GitLab CI jobs.
 
 This comes with several risks that you can read about in the
-[GitLab CI Runner documentation](https://docs.gitlab.com/runner/executors/kubernetes.html#using-docker-in-your-builds).
+[GitLab CI Runner documentation](../../../runner/executors/kubernetes.html#using-docker-in-your-builds).
 
 If you are okay with the risks, and your GitLab CI Runner instance is registered
 against a specific project in GitLab that you trust the CI jobs of, you can
@@ -164,7 +164,7 @@ Each key name in the Secret will be used as a filename in the directory, with th
 file content being the value associated with the key.
 
 More information on how GitLab Runner uses these certificates can be found in the
-[Runner Documentation](https://docs.gitlab.com/runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates).
+[Runner Documentation](../../../runner/configuration/tls-self-signed.html#supported-options-for-self-signed-certificates).
 
  - The key/file name used should be in the format `<gitlab-hostname>.crt`. For example: `gitlab.your-domain.com.crt`.
  - Any intermediate certificates need to be concatenated to your server certificate in the same file.

doc/install/kubernetes/index.md

@@ -19,7 +19,7 @@ should be deployed, upgraded, and configured.
 ## GitLab-Omnibus Chart (Recommended)
 > **Note**: This chart is in beta while [additional features](https://gitlab.com/charts/charts.gitlab.io/issues/68) are being added.
 
-This chart is the best available way to operate GitLab on Kubernetes. It deploys and configures nearly all features of GitLab, including: a [Runner](https://docs.gitlab.com/runner/), [Container Registry](https://docs.gitlab.com/ee/user/project/container_registry.html#gitlab-container-registry), [Mattermost](https://docs.gitlab.com/omnibus/gitlab-mattermost/), [automatic SSL](https://github.com/kubernetes/charts/tree/master/stable/kube-lego), and a [load balancer](https://github.com/kubernetes/ingress/tree/master/controllers/nginx). It is based on our [GitLab Omnibus Docker Images](https://docs.gitlab.com/omnibus/docker/README.html).
+This chart is the best available way to operate GitLab on Kubernetes. It deploys and configures nearly all features of GitLab, including: a [Runner](../../../runner/), [Container Registry](../../user/project/container_registry.html#gitlab-container-registry), [Mattermost](../../../omnibus/gitlab-mattermost/), [automatic SSL](https://github.com/kubernetes/charts/tree/master/stable/kube-lego), and a [load balancer](https://github.com/kubernetes/ingress/tree/master/controllers/nginx). It is based on our [GitLab Omnibus Docker Images](../../../omnibus/docker/README.html).
 
 Once the [cloud native charts](#upcoming-cloud-native-helm-charts) are ready for production use, this chart will be deprecated. Due to the difficulty in supporting upgrades to the new architecture, migrating will require exporting data out of this instance and importing it into the new deployment.