Merge remote-tracking branch 'upstream/master' into ce-to-ee-2018-11-12

doc/install/kubernetes/gitlab_runner_chart.md

 # GitLab Runner Helm Chart
 > **Note:**
-These charts have been tested on Google Kubernetes Engine and Azure Container Service. Other Kubernetes installations may work as well, if not please [open an issue](https://gitlab.com/charts/gitlab-runner/issues).
+These charts have been tested on Google Kubernetes Engine and Azure Container Service. Other Kubernetes installations may work as well, if not please [open an issue](https://gitlab.com/gitlab-org/gitlab-runner/issues).
 
 The `gitlab-runner` Helm chart deploys a GitLab Runner instance into your
 Kubernetes cluster.
@@ -132,7 +132,7 @@ runners:
 
 If your cluster has RBAC enabled, you can choose to either have the chart create its own service account or provide one.
 
-To have the chart create the service account for you, set `rbac.create` to true. 
+To have the chart create the service account for you, set `rbac.create` to true.
 
 ### Controlling maximum Runner concurrency
 

doc/install/requirements.md

@@ -36,7 +36,7 @@ Please consider using a virtual machine to run GitLab.
 GitLab requires Ruby (MRI) 2.3. Support for Ruby versions below 2.3 (2.1, 2.2) will stop with GitLab 8.13.
 
 You will have to use the standard MRI implementation of Ruby.
-We love [JRuby](http://jruby.org/) and [Rubinius](http://rubini.us/) but GitLab
+We love [JRuby](https://www.jruby.org/) and [Rubinius](https://rubinius.com) but GitLab
 needs several Gems that have native extensions.
 
 ## Hardware requirements

doc/integration/auth0.md

@@ -3,7 +3,7 @@
 To enable the Auth0 OmniAuth provider, you must create an Auth0 account, and an
 application.
 
-1. Sign in to the [Auth0 Console](https://manage.auth0.com). If you need to
+1. Sign in to the [Auth0 Console](https://auth0.com/auth/login). If you need to
 create an account, you can do so at the same link.
 
 1. Select "New App/API".

doc/user/project/clusters/index.md

@@ -146,9 +146,10 @@ service accounts and privileges in order to install and run
 - A `gitlab` service account with `cluster-admin` privileges will be created in the
   `default` namespace, which will be used by GitLab to manage the newly created cluster.
 
-- A project service account with `edit` privileges will be created in
-  the project namespace (also created by GitLab), which will be used in
-  [deployment jobs](#deployment-variables).
+- A project service account with [`edit`
+  privileges](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
+  will be created in the project namespace (also created by GitLab), which will
+  be used in [deployment jobs](#deployment-variables).
 
   NOTE: **Note:**
   Restricted service account for deployment was [introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/51716) in GitLab 11.5.

doc/user/project/import/clearcase.md

 # Migrating from ClearCase
 
-[ClearCase](https://www-03.ibm.com/software/products/en/clearcase/) is a set of
+[ClearCase](https://www.ibm.com/us-en/marketplace/rational-clearcase) is a set of
 tools developed by IBM which also include a centralized version control system
 similar to Git.
 

doc/user/project/integrations/mattermost.md

@@ -4,9 +4,9 @@
 
 To enable Mattermost integration you must create an incoming webhook integration:
 
-1. Sign in to your Mattermost instance
-1. Visit incoming webhooks, that will be something like: https://mattermost.example/your_team_name/integrations/incoming_webhooks/add
-1. Choose a display name, description and channel, those can be overridden on GitLab
+1. Sign in to your Mattermost instance.
+1. Visit incoming webhooks, that will be something like: `https://mattermost.example.com/your_team_name/integrations/incoming_webhooks/add`.
+1. Choose a display name, description and channel, those can be overridden on GitLab.
 1. Save it, copy the **Webhook URL**, we'll need this later for GitLab.
 
 There might be some cases that Incoming Webhooks are blocked by admin, ask your mattermost admin to enable