Merge branch 'master' into zj-create-mattermost-team

22 files changed, 386 insertions, 249 deletions

diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 19316458d49..8de0cc5af5c 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -1,4 +1,4 @@
-# GitLab Pages Administration
+# GitLab Pages administration
 
 > **Notes:**
 - [Introduced][ee-80] in GitLab EE 8.3.
@@ -6,6 +6,7 @@
 - GitLab Pages [were ported][ce-14605] to Community Edition in GitLab 8.17.
 - This guide is for Omnibus GitLab installations. If you have installed
   GitLab from source, follow the [Pages source installation document](source.md).
+- To learn how to use GitLab Pages, read the [user documentation][pages-userguide].
 
 ---
 
@@ -14,9 +15,6 @@ sure to read the [changelog](#changelog) if you are upgrading to a new GitLab
 version as it may include new features and changes needed to be made in your
 configuration.
 
-If you are looking for ways to upload your static content in GitLab Pages, you
-probably want to read the [user documentation][pages-userguide].
-
 ## Overview
 
 GitLab Pages makes use of the [GitLab Pages daemon], a simple HTTP server
@@ -32,7 +30,7 @@ In the case of custom domains, the Pages daemon needs to listen on ports `80`
 and/or `443`. For that reason, there is some flexibility in the way which you
 can set it up:
 
-1. Run the pages daemon in the same server as GitLab, listening on a secondary IP
+1. Run the pages daemon in the same server as GitLab, listening on a secondary IP.
 1. Run the pages daemon in a separate server. In that case, the
    [Pages path](#change-storage-path) must also be present in the server that
    the pages daemon is installed, so you will have to share it via network.
@@ -64,11 +62,11 @@ you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
 host that GitLab runs. For example, an entry would look like this:
 
 ```
-*.example.io. 1800 IN A 1.2.3.4
+*.example.io. 1800 IN A 1.1.1.1
 ```
 
 where `example.io` is the domain under which GitLab Pages will be served
-and `1.2.3.4` is the IP address of your GitLab instance.
+and `1.1.1.1` is the IP address of your GitLab instance.
 
 > **Note:**
 You should not use the GitLab domain to serve user pages. For more information
@@ -78,101 +76,126 @@ see the [security section](#security).
 
 ## Configuration
 
-Depending on your needs, you can install GitLab Pages in four different ways.
+Depending on your needs, you can set up GitLab Pages in 4 different ways.
+The following options are listed from the easiest setup to the most
+advanced one. The absolute minimum requirement is to set up the wildcard DNS
+since that is needed in all configurations.
 
-### Option 1. Custom domains with HTTPS support
+### Wildcard domains
 
-| URL scheme | Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `https://page.example.io` and `https://page.com` | yes |  redirects to HTTPS | yes | yes |
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+>
+>---
+>
+URL scheme: `http://page.example.io`
 
-Pages enabled, daemon is enabled AND pages has external IP support enabled.
-In that case, the pages daemon is running, NGINX still proxies requests to
-the daemon but the daemon is also able to receive requests from the outside
-world. Custom domains and TLS are supported.
+This is the minimum setup that you can use Pages with. It is the base for all
+other setups as described below. Nginx will proxy all requests to the daemon.
+The Pages daemon doesn't listen to the outside world.
 
-1. Edit `/etc/gitlab/gitlab.rb`:
+1. Set the external URL for GitLab Pages in `/etc/gitlab/gitlab.rb`:
 
     ```ruby
-    pages_external_url "https://example.io"
-    nginx['listen_addresses'] = ['1.1.1.1']
-    pages_nginx['enable'] = false
-    gitlab_pages['cert'] = "/etc/gitlab/ssl/example.io.crt"
-    gitlab_pages['cert_key'] = "/etc/gitlab/ssl/example.io.key"
-    gitlab_pages['external_http'] = '1.1.1.2:80'
-    gitlab_pages['external_https'] = '1.1.1.2:443'
+    pages_external_url 'http://example.io'
     ```
 
-    where `1.1.1.1` is the primary IP address that GitLab is listening to and
-    `1.1.1.2` the secondary IP where the GitLab Pages daemon listens to.
-
 1. [Reconfigure GitLab][reconfigure]
 
-### Option 2. Custom domains without HTTPS support
+### Wildcard domains with TLS support
 
-| URL scheme |  Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `http://page.example.io` and `http://page.com` | no  |  yes    | no  | yes |
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+- Wildcard TLS certificate
+>
+>---
+>
+URL scheme: `https://page.example.io`
 
-Pages enabled, daemon is enabled AND pages has external IP support enabled.
-In that case, the pages daemon is running, NGINX still proxies requests to
-the daemon but the daemon is also able to receive requests from the outside
-world. Custom domains and TLS are supported.
+Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
+outside world.
 
-1. Edit `/etc/gitlab/gitlab.rb`:
+1. Place the certificate and key inside `/etc/gitlab/ssl`
+1. In `/etc/gitlab/gitlab.rb` specify the following configuration:
 
     ```ruby
-    pages_external_url "http://example.io"
-    nginx['listen_addresses'] = ['1.1.1.1']
-    pages_nginx['enable'] = false
-    gitlab_pages['external_http'] = '1.1.1.2:80'
+    pages_external_url 'https://example.io'
+
+    pages_nginx['redirect_http_to_https'] = true
+    pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages-nginx.crt"
+    pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages-nginx.key"
     ```
 
-    where `1.1.1.1` is the primary IP address that GitLab is listening to and
-    `1.1.1.2` the secondary IP where the GitLab Pages daemon listens to.
+    where `pages-nginx.crt` and `pages-nginx.key` are the SSL cert and key,
+    respectively.
 
 1. [Reconfigure GitLab][reconfigure]
 
-### Option 3. Wildcard HTTPS domain without custom domains
+## Advanced configuration
 
-| URL scheme | Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `https://page.example.io` | yes |  no | no | no |
+In addition to the wildcard domains, you can also have the option to configure
+GitLab Pages to work with custom domains. Again, there are two options here:
+support custom domains with and without TLS certificates. The easiest setup is
+that without TLS certificates.
 
-Pages enabled, daemon is enabled and NGINX will proxy all requests to the
-daemon. Pages daemon doesn't listen to the outside world.
+### Custom domains
 
-1. Place the certificate and key inside `/etc/gitlab/ssl`
-1. In `/etc/gitlab/gitlab.rb` specify the following configuration:
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+- Secondary IP
+>
+---
+>
+URL scheme: `http://page.example.io` and `http://domain.com`
 
-    ```ruby
-    pages_external_url 'https://example.io'
+In that case, the pages daemon is running, Nginx still proxies requests to
+the daemon but the daemon is also able to receive requests from the outside
+world. Custom domains are supported, but no TLS.
 
-    pages_nginx['redirect_http_to_https'] = true
-    pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/pages-nginx.crt"
-    pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/pages-nginx.key"
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+    ```ruby
+    pages_external_url "http://example.io"
+    nginx['listen_addresses'] = ['1.1.1.1']
+    pages_nginx['enable'] = false
+    gitlab_pages['external_http'] = '1.1.1.2:80'
     ```
 
-    where `pages-nginx.crt` and `pages-nginx.key` are the SSL cert and key,
-    respectively.
+    where `1.1.1.1` is the primary IP address that GitLab is listening to and
+    `1.1.1.2` the secondary IP where the GitLab Pages daemon listens to.
 
 1. [Reconfigure GitLab][reconfigure]
 
-### Option 4. Wildcard HTTP domain without custom domains
+### Custom domains with TLS support
 
-| URL scheme | Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `http://page.example.io`  | no  |  no | no | no |
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+- Wildcard TLS certificate
+- Secondary IP
+>
+---
+>
+URL scheme: `https://page.example.io` and `https://domain.com`
 
-Pages enabled, daemon is enabled and NGINX will proxy all requests to the
-daemon. Pages daemon doesn't listen to the outside world.
+In that case, the pages daemon is running, Nginx still proxies requests to
+the daemon but the daemon is also able to receive requests from the outside
+world. Custom domains and TLS are supported.
 
-1. Set the external URL for GitLab Pages in `/etc/gitlab/gitlab.rb`:
+1. Edit `/etc/gitlab/gitlab.rb`:
 
     ```ruby
-    pages_external_url 'http://example.io'
+    pages_external_url "https://example.io"
+    nginx['listen_addresses'] = ['1.1.1.1']
+    pages_nginx['enable'] = false
+    gitlab_pages['cert'] = "/etc/gitlab/ssl/example.io.crt"
+    gitlab_pages['cert_key'] = "/etc/gitlab/ssl/example.io.key"
+    gitlab_pages['external_http'] = '1.1.1.2:80'
+    gitlab_pages['external_https'] = '1.1.1.2:443'
     ```
 
+    where `1.1.1.1` is the primary IP address that GitLab is listening to and
+    `1.1.1.2` the secondary IP where the GitLab Pages daemon listens to.
+
 1. [Reconfigure GitLab][reconfigure]
 
 ## Change storage path
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index 0718c05a6f4..463715e48ca 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -17,22 +17,54 @@ Pages to the latest supported version.
 
 ## Prerequisites
 
-[Read the Omnibus prerequisites section.](index.md#prerequisites)
+Before proceeding with the Pages configuration, you will need to:
+
+1. Have a separate domain under which the GitLab Pages will be served. In this
+   document we assume that to be `example.io`.
+1. Configure a **wildcard DNS record**.
+1. (Optional) Have a **wildcard certificate** for that domain if you decide to
+   serve Pages under HTTPS.
+1. (Optional but recommended) Enable [Shared runners](../../ci/runners/README.md)
+   so that your users don't have to bring their own.
+
+### DNS configuration
+
+GitLab Pages expect to run on their own virtual host. In your DNS server/provider
+you need to add a [wildcard DNS A record][wiki-wildcard-dns] pointing to the
+host that GitLab runs. For example, an entry would look like this:
+
+```
+*.example.io. 1800 IN A 1.1.1.1
+```
+
+where `example.io` is the domain under which GitLab Pages will be served
+and `1.1.1.1` is the IP address of your GitLab instance.
+
+> **Note:**
+You should not use the GitLab domain to serve user pages. For more information
+see the [security section](#security).
+
+[wiki-wildcard-dns]: https://en.wikipedia.org/wiki/Wildcard_DNS_record
 
 ## Configuration
 
-Depending on your needs, you can install GitLab Pages in four different ways.
+Depending on your needs, you can set up GitLab Pages in 4 different ways.
+The following options are listed from the easiest setup to the most
+advanced one. The absolute minimum requirement is to set up the wildcard DNS
+since that is needed in all configurations.
 
-### Option 1. Custom domains with HTTPS support
+### Wildcard domains
 
-| URL scheme | Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `https://page.example.io` and `https://page.com` | yes |  redirects to HTTPS | yes | yes |
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+>
+>---
+>
+URL scheme: `http://page.example.io`
 
-Pages enabled, daemon is enabled AND pages has external IP support enabled.
-In that case, the pages daemon is running, NGINX still proxies requests to
-the daemon but the daemon is also able to receive requests from the outside
-world. Custom domains and TLS are supported.
+This is the minimum setup that you can use Pages with. It is the base for all
+other setups as described below. Nginx will proxy all requests to the daemon.
+The Pages daemon doesn't listen to the outside world.
 
 1. Install the Pages daemon:
 
@@ -44,10 +76,14 @@ world. Custom domains and TLS are supported.
     sudo -u git -H make
     ```
 
-1. Edit `gitlab.yml` to look like the example below. You need to change the
-   `host` to the FQDN under which GitLab Pages will be served. Set
-   `external_http` and `external_https` to the secondary IP on which the pages
-   daemon will listen for connections:
+1. Go to the GitLab installation directory:
+
+     ```bash
+     cd /home/git/gitlab
+     ```
+
+1. Edit `gitlab.yml` and under the `pages` setting, set `enabled` to `true` and
+   the `host` to the FQDN under which GitLab Pages will be served:
 
      ```yaml
      ## GitLab Pages
@@ -57,25 +93,10 @@ world. Custom domains and TLS are supported.
        # path: shared/pages
 
        host: example.io
-       port: 443
-       https: true
-
-       external_http: 1.1.1.2:80
-       external_https: 1.1.1.2:443
+       port: 80
+       https: false
      ```
 
-1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
-   order to enable the pages daemon. In `gitlab_pages_options` the
-   `-pages-domain`, `-listen-http` and `-listen-https` must match the `host`,
-   `external_http` and `external_https` settings that you set above respectively.
-   The `-root-cert` and `-root-key` settings are the wildcard TLS certificates
-   of the `example.io` domain:
-
-    ```
-    gitlab_pages_enabled=true
-    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 1.1.1.2:80 -listen-https 1.1.1.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
-    ```
-
 1. Copy the `gitlab-pages-ssl` Nginx configuration file:
 
     ```bash
@@ -85,22 +106,21 @@ world. Custom domains and TLS are supported.
 
       Replace `gitlab-pages-ssl` with `gitlab-pages` if you are not using SSL.
 
-1. Edit all GitLab related configs in `/etc/nginx/site-available/` and replace
-   `0.0.0.0` with `1.1.1.1`, where `1.1.1.1` the primary IP where GitLab
-   listens to.
 1. Restart NGINX
 1. [Restart GitLab][restart]
 
-### Option 2. Custom domains without HTTPS support
+### Wildcard domains with TLS support
 
-| URL scheme |  Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `http://page.example.io` and `http://page.com` | no  |  yes    | no  | yes |
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+- Wildcard TLS certificate
+>
+>---
+>
+URL scheme: `https://page.example.io`
 
-Pages enabled, daemon is enabled AND pages has external IP support enabled.
-In that case, the pages daemon is running, NGINX still proxies requests to
-the daemon but the daemon is also able to receive requests from the outside
-world. Custom domains and TLS are supported.
+Nginx will proxy all requests to the daemon. Pages daemon doesn't listen to the
+outside world.
 
 1. Install the Pages daemon:
 
@@ -112,34 +132,20 @@ world. Custom domains and TLS are supported.
     sudo -u git -H make
     ```
 
-1. Edit `gitlab.yml` to look like the example below. You need to change the
-   `host` to the FQDN under which GitLab Pages will be served. Set
-   `external_http` to the secondary IP on which the pages daemon will listen
-   for connections:
+1. In `gitlab.yml`, set the port to `443` and https to `true`:
 
-     ```yaml
+     ```bash
+     ## GitLab Pages
      pages:
        enabled: true
        # The location where pages are stored (default: shared/pages).
        # path: shared/pages
 
        host: example.io
-       port: 80
-       https: false
-
-       external_http: 1.1.1.2:80
+       port: 443
+       https: true
      ```
 
-1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
-   order to enable the pages daemon. In `gitlab_pages_options` the
-   `-pages-domain` and `-listen-http` must match the `host` and `external_http`
-   settings that you set above respectively:
-
-    ```
-    gitlab_pages_enabled=true
-    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 1.1.1.2:80"
-    ```
-
 1. Copy the `gitlab-pages-ssl` Nginx configuration file:
 
     ```bash
@@ -149,20 +155,30 @@ world. Custom domains and TLS are supported.
 
       Replace `gitlab-pages-ssl` with `gitlab-pages` if you are not using SSL.
 
-1. Edit all GitLab related configs in `/etc/nginx/site-available/` and replace
-   `0.0.0.0` with `1.1.1.1`, where `1.1.1.1` the primary IP where GitLab
-   listens to.
 1. Restart NGINX
 1. [Restart GitLab][restart]
 
-### Option 3. Wildcard HTTPS domain without custom domains
 
-| URL scheme | Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `https://page.example.io` | yes |  no | no | no |
+## Advanced configuration
+
+In addition to the wildcard domains, you can also have the option to configure
+GitLab Pages to work with custom domains. Again, there are two options here:
+support custom domains with and without TLS certificates. The easiest setup is
+that without TLS certificates.
+
+### Custom domains
 
-Pages enabled, daemon is enabled and NGINX will proxy all requests to the
-daemon. Pages daemon doesn't listen to the outside world.
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+- Secondary IP
+>
+---
+>
+URL scheme: `http://page.example.io` and `http://domain.com`
+
+In that case, the pages daemon is running, Nginx still proxies requests to
+the daemon but the daemon is also able to receive requests from the outside
+world. Custom domains are supported, but no TLS.
 
 1. Install the Pages daemon:
 
@@ -173,20 +189,35 @@ daemon. Pages daemon doesn't listen to the outside world.
     sudo -u git -H git checkout v0.2.4
     sudo -u git -H make
     ```
-1. In `gitlab.yml`, set the port to `443` and https to `true`:
 
-     ```bash
-     ## GitLab Pages
+1. Edit `gitlab.yml` to look like the example below. You need to change the
+   `host` to the FQDN under which GitLab Pages will be served. Set
+   `external_http` to the secondary IP on which the pages daemon will listen
+   for connections:
+
+     ```yaml
      pages:
        enabled: true
        # The location where pages are stored (default: shared/pages).
        # path: shared/pages
 
        host: example.io
-       port: 443
-       https: true
+       port: 80
+       https: false
+
+       external_http: 1.1.1.2:80
      ```
 
+1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
+   order to enable the pages daemon. In `gitlab_pages_options` the
+   `-pages-domain` and `-listen-http` must match the `host` and `external_http`
+   settings that you set above respectively:
+
+    ```
+    gitlab_pages_enabled=true
+    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 1.1.1.2:80"
+    ```
+
 1. Copy the `gitlab-pages-ssl` Nginx configuration file:
 
     ```bash
@@ -196,17 +227,26 @@ daemon. Pages daemon doesn't listen to the outside world.
 
       Replace `gitlab-pages-ssl` with `gitlab-pages` if you are not using SSL.
 
+1. Edit all GitLab related configs in `/etc/nginx/site-available/` and replace
+   `0.0.0.0` with `1.1.1.1`, where `1.1.1.1` the primary IP where GitLab
+   listens to.
 1. Restart NGINX
 1. [Restart GitLab][restart]
 
-### Option 4. Wildcard HTTP domain without custom domains
+### Custom domains with TLS support
 
-| URL scheme | Wildcard certificate | Custom domain with HTTP support | Custom domain with HTTPS support | Secondary IP |
-| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|
-| `http://page.example.io`  | no  |  no | no | no |
+>**Requirements:**
+- [Wildcard DNS setup](#dns-configuration)
+- Wildcard TLS certificate
+- Secondary IP
+>
+---
+>
+URL scheme: `https://page.example.io` and `https://domain.com`
 
-Pages enabled, daemon is enabled and NGINX will proxy all requests to the
-daemon. Pages daemon doesn't listen to the outside world.
+In that case, the pages daemon is running, Nginx still proxies requests to
+the daemon but the daemon is also able to receive requests from the outside
+world. Custom domains and TLS are supported.
 
 1. Install the Pages daemon:
 
@@ -218,14 +258,10 @@ daemon. Pages daemon doesn't listen to the outside world.
     sudo -u git -H make
     ```
 
-1. Go to the GitLab installation directory:
-
-     ```bash
-     cd /home/git/gitlab
-     ```
-
-1. Edit `gitlab.yml` and under the `pages` setting, set `enabled` to `true` and
-   the `host` to the FQDN under which GitLab Pages will be served:
+1. Edit `gitlab.yml` to look like the example below. You need to change the
+   `host` to the FQDN under which GitLab Pages will be served. Set
+   `external_http` and `external_https` to the secondary IP on which the pages
+   daemon will listen for connections:
 
      ```yaml
      ## GitLab Pages
@@ -235,10 +271,25 @@ daemon. Pages daemon doesn't listen to the outside world.
        # path: shared/pages
 
        host: example.io
-       port: 80
-       https: false
+       port: 443
+       https: true
+
+       external_http: 1.1.1.2:80
+       external_https: 1.1.1.2:443
      ```
 
+1. Edit `/etc/default/gitlab` and set `gitlab_pages_enabled` to `true` in
+   order to enable the pages daemon. In `gitlab_pages_options` the
+   `-pages-domain`, `-listen-http` and `-listen-https` must match the `host`,
+   `external_http` and `external_https` settings that you set above respectively.
+   The `-root-cert` and `-root-key` settings are the wildcard TLS certificates
+   of the `example.io` domain:
+
+    ```
+    gitlab_pages_enabled=true
+    gitlab_pages_options="-pages-domain example.io -pages-root $app_root/shared/pages -listen-proxy 127.0.0.1:8090 -listen-http 1.1.1.2:80 -listen-https 1.1.1.2:443 -root-cert /path/to/example.io.crt -root-key /path/to/example.io.key
+    ```
+
 1. Copy the `gitlab-pages-ssl` Nginx configuration file:
 
     ```bash
@@ -248,9 +299,27 @@ daemon. Pages daemon doesn't listen to the outside world.
 
       Replace `gitlab-pages-ssl` with `gitlab-pages` if you are not using SSL.
 
+1. Edit all GitLab related configs in `/etc/nginx/site-available/` and replace
+   `0.0.0.0` with `1.1.1.1`, where `1.1.1.1` the primary IP where GitLab
+   listens to.
 1. Restart NGINX
 1. [Restart GitLab][restart]
 
+## Change storage path
+
+Follow the steps below to change the default path where GitLab Pages' contents
+are stored.
+
+1. Pages are stored by default in `/var/opt/gitlab/gitlab-rails/shared/pages`.
+   If you wish to store them in another location you must set it up in
+   `/etc/gitlab/gitlab.rb`:
+
+     ```ruby
+     gitlab_rails['pages_path'] = "/mnt/storage/pages"
+     ```
+
+1. [Reconfigure GitLab][reconfigure]
+
 ## NGINX caveats
 
 >**Note:**
diff --git a/doc/api/deploy_keys.md b/doc/api/deploy_keys.md
index 284d5f88c55..8d0dbfd7597 100644
--- a/doc/api/deploy_keys.md
+++ b/doc/api/deploy_keys.md
@@ -137,7 +137,7 @@ Example response:
 
 ## Delete deploy key
 
-Delete a deploy key from a project
+Removes a deploy key from the project. If the deploy is used only for this project, it will be deleted from the system.
 
 ```
 DELETE /projects/:id/deploy_keys/:key_id
@@ -156,14 +156,11 @@ Example response:
 
 ```json
 {
-   "updated_at" : "2015-08-29T12:50:57.259Z",
-   "key" : "ssh-rsa AAAA...",
-   "public" : false,
-   "title" : "My deploy key",
-   "user_id" : null,
-   "created_at" : "2015-08-29T12:50:57.259Z",
-   "fingerprint" : "6a:33:1f:74:51:c0:39:81:79:ec:7a:31:f8:40:20:43",
-   "id" : 13
+  "id": 6,
+  "deploy_key_id": 14,
+  "project_id": 1,
+  "created_at" : "2015-08-29T12:50:57.259Z",
+  "updated_at" : "2015-08-29T12:50:57.259Z"
 }
 ```
 
@@ -190,27 +187,3 @@ Example response:
    "created_at" : "2015-08-29T12:44:31.550Z"
 }
 ```
-
-## Disable a deploy key
-
-Disable a deploy key for a project. Returns the disabled key.
-
-```bash
-curl --request DELETE --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" https://gitlab.example.com/api/v3/projects/5/deploy_keys/13/disable
-```
-
-| Attribute | Type | Required | Description |
-| --------- | ---- | -------- | ----------- |
-| `id`      | integer | yes | The ID of the project |
-| `key_id`  | integer | yes | The ID of the deploy key |
-
-Example response:
-
-```json
-{
-   "key" : "ssh-rsa AAAA...",
-   "id" : 12,
-   "title" : "My deploy key",
-   "created_at" : "2015-08-29T12:44:31.550Z"
-}
-```
diff --git a/doc/api/keys.md b/doc/api/keys.md
index b68f08a007d..3b55c2baf56 100644
--- a/doc/api/keys.md
+++ b/doc/api/keys.md
@@ -33,7 +33,6 @@ Parameters:
     "twitter": "",
     "website_url": "",
     "email": "john@example.com",
-    "theme_id": 2,
     "color_scheme_id": 1,
     "projects_limit": 10,
     "current_sign_in_at": null,
diff --git a/doc/api/milestones.md b/doc/api/milestones.md
index 12497acff98..bf7dcc008e9 100644
--- a/doc/api/milestones.md
+++ b/doc/api/milestones.md
@@ -103,3 +103,16 @@ Parameters:
 
 - `id` (required) - The ID of a project
 - `milestone_id` (required) - The ID of a project milestone
+
+## Get all merge requests assigned to a single milestone
+
+Gets all merge requests assigned to a single project milestone.
+
+```
+GET /projects/:id/milestones/:milestone_id/merge_requests
+```
+
+Parameters:
+
+- `id` (required) - The ID of a project
+- `milestone_id` (required) - The ID of a project milestone
\ No newline at end of file
diff --git a/doc/api/session.md b/doc/api/session.md
index f776424023e..d7809716fbe 100644
--- a/doc/api/session.md
+++ b/doc/api/session.md
@@ -41,7 +41,6 @@ Example response:
   "twitter": "",
   "website_url": "",
   "email": "john@example.com",
-  "theme_id": 1,
   "color_scheme_id": 1,
   "projects_limit": 10,
   "current_sign_in_at": "2015-07-07T07:10:58.392Z",
diff --git a/doc/api/users.md b/doc/api/users.md
index ed3469521fc..626f7e63e3e 100644
--- a/doc/api/users.md
+++ b/doc/api/users.md
@@ -72,7 +72,6 @@ GET /users
     "organization": "",
     "last_sign_in_at": "2012-06-01T11:41:01Z",
     "confirmed_at": "2012-05-23T09:05:22Z",
-    "theme_id": 1,
     "color_scheme_id": 2,
     "projects_limit": 100,
     "current_sign_in_at": "2012-06-02T06:36:55Z",
@@ -105,7 +104,6 @@ GET /users
     "organization": "",
     "last_sign_in_at": null,
     "confirmed_at": "2012-05-30T16:53:06.148Z",
-    "theme_id": 1,
     "color_scheme_id": 3,
     "projects_limit": 100,
     "current_sign_in_at": "2014-03-19T17:54:13Z",
@@ -198,7 +196,6 @@ Parameters:
   "organization": "",
   "last_sign_in_at": "2012-06-01T11:41:01Z",
   "confirmed_at": "2012-05-23T09:05:22Z",
-  "theme_id": 1,
   "color_scheme_id": 2,
   "projects_limit": 100,
   "current_sign_in_at": "2012-06-02T06:36:55Z",
@@ -323,7 +320,6 @@ GET /user
   "organization": "",
   "last_sign_in_at": "2012-06-01T11:41:01Z",
   "confirmed_at": "2012-05-23T09:05:22Z",
-  "theme_id": 1,
   "color_scheme_id": 2,
   "projects_limit": 100,
   "current_sign_in_at": "2012-06-02T06:36:55Z",
@@ -369,7 +365,6 @@ GET /user
   "organization": "",
   "last_sign_in_at": "2012-06-01T11:41:01Z",
   "confirmed_at": "2012-05-23T09:05:22Z",
-  "theme_id": 1,
   "color_scheme_id": 2,
   "projects_limit": 100,
   "current_sign_in_at": "2012-06-02T06:36:55Z",
diff --git a/doc/api/v3_to_v4.md b/doc/api/v3_to_v4.md
index 84ff72bc36c..0e7c5251329 100644
--- a/doc/api/v3_to_v4.md
+++ b/doc/api/v3_to_v4.md
@@ -24,3 +24,5 @@ changes are in V4:
   - `/dockerfiles/:key`
 - Moved `/projects/fork/:id` to `/projects/:id/fork`
 - Endpoints `/projects/owned`, `/projects/visible`, `/projects/starred` & `/projects/all` are consolidated into `/projects` using query parameters
+- Return pagination headers for all endpoints that return an array
+- Removed `DELETE projects/:id/deploy_keys/:key_id/disable`. Use `DELETE projects/:id/deploy_keys/:key_id` instead
diff --git a/doc/ci/environments.md b/doc/ci/environments.md
index 3bba94f8b83..3c31ba45d3d 100644
--- a/doc/ci/environments.md
+++ b/doc/ci/environments.md
@@ -535,6 +535,7 @@ deploy_review:
     - master
 
 stop_review:
+  stage: deploy
   variables:
     GIT_STRATEGY: none
   script:
@@ -555,7 +556,9 @@ when their associated branch is deleted.
 
 When you have an environment that has a stop action defined (typically when
 the environment describes a review app), GitLab will automatically trigger a
-stop action when the associated branch is deleted.
+stop action when the associated branch is deleted. The `stop_review` job must
+be in the same `stage` as the `deploy_review` one in order for the environment
+to automatically stop.
 
 You can read more in the [`.gitlab-ci.yml` reference][onstop].
 
diff --git a/doc/ci/pipelines.md b/doc/ci/pipelines.md
index 9d294240d9d..db92a4b0d80 100644
--- a/doc/ci/pipelines.md
+++ b/doc/ci/pipelines.md
@@ -91,7 +91,7 @@ total running time should be:
 
 ## Badges
 
-Job status and test coverage report badges are available. You can find their
+Pipeline status and test coverage report badges are available. You can find their
 respective link in the [Pipelines settings] page.
 
 [jobs]: #jobs
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 63be61d1bca..a73598df812 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -690,6 +690,8 @@ The `stop_review_app` job is **required** to have the following keywords defined
 - `when` - [reference](#when)
 - `environment:name`
 - `environment:action`
+- `stage` should be the same as the `review_app` in order for the environment
+  to stop automatically when the branch is deleted
 
 #### dynamic environments
 
diff --git a/doc/development/gotchas.md b/doc/development/gotchas.md
index 0f78e8238af..565d4b33457 100644
--- a/doc/development/gotchas.md
+++ b/doc/development/gotchas.md
@@ -3,7 +3,7 @@
 The purpose of this guide is to document potential "gotchas" that contributors
 might encounter or should avoid during development of GitLab CE and EE.
 
-## Don't `describe` symbols
+## Do not `describe` symbols
 
 Consider the following model spec:
 
@@ -32,7 +32,7 @@ spec/models/user_spec.rb|6 error|  Failure/Error: u = described_class.new NoMeth
 Except for the top-level `describe` block, always provide a String argument to
 `describe`.
 
-## Don't assert against the absolute value of a sequence-generated attribute
+## Do not assert against the absolute value of a sequence-generated attribute
 
 Consider the following factory:
 
@@ -121,7 +121,7 @@ describe API::Labels do
 end
 ```
 
-## Don't `rescue Exception`
+## Do not `rescue Exception`
 
 See ["Why is it bad style to `rescue Exception => e` in Ruby?"][Exception].
 
@@ -130,7 +130,7 @@ Rubocop](https://gitlab.com/gitlab-org/gitlab-ce/blob/8-4-stable/.rubocop.yml#L9
 
 [Exception]: http://stackoverflow.com/q/10048173/223897
 
-## Don't use inline JavaScript in views
+## Do not use inline JavaScript in views
 
 Using the inline `:javascript` Haml filters comes with a
 performance overhead. Using inline JavaScript is not a good way to structure your code and should be avoided.
diff --git a/doc/development/limit_ee_conflicts.md b/doc/development/limit_ee_conflicts.md
index 568dedf1669..2d82b09f301 100644
--- a/doc/development/limit_ee_conflicts.md
+++ b/doc/development/limit_ee_conflicts.md
@@ -2,19 +2,26 @@
 
 This guide contains best-practices for avoiding conflicts between CE and EE.
 
-## Context
+## Daily CE Upstream merge
 
-Usually, GitLab Community Edition is merged into the Enterprise Edition once a
-week. During these merges, it's very common to get conflicts when some changes
-in CE do not apply cleanly to EE.
+GitLab Community Edition is merged daily into the Enterprise Edition (look for
+the [`CE Upstream` merge requests]). The daily merge is currently done manually
+by four individuals.
 
-There are a few things that can help you as a developer to:
+**If a developer pings you in a `CE Upstream` merge request for help with
+resolving conflicts, please help them because it means that you didn't do your
+job to reduce the conflicts nor to ease their resolution in the first place!**
 
-- know when your merge request to CE will conflict when merged to EE
-- avoid such conflicts in the first place
-- ease future conflict resolutions if conflict is inevitable
+To avoid the conflicts beforehand when working on CE, there are a few tools and
+techniques that can help you:
 
-## Check the `rake ee_compat_check` in your merge requests
+- know what are the usual types of conflicts and how to prevent them
+- the CI `rake ee_compat_check` job tells you if you need to open an EE-version
+  of your CE merge request
+
+[`CE Upstream` merge requests]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests?label_name%5B%5D=CE+upstream
+
+## Check the status of the CI `rake ee_compat_check` job
 
 For each commit (except on `master`), the `rake ee_compat_check` CI job tries to
 detect if the current branch's changes will conflict during the CE->EE merge.
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 0f07085942a..5ba338ba7d1 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -39,6 +39,7 @@ The GitLab installation consists of setting up the following components:
 1. Packages / Dependencies
 1. Ruby
 1. Go
+1. Node
 1. System Users
 1. Database
 1. Redis
@@ -63,7 +64,7 @@ up-to-date and install it.
 
 Install the required packages (needed to compile Ruby and native extensions to Ruby gems):
 
-    sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate python-docutils pkg-config cmake nodejs
+    sudo apt-get install -y build-essential zlib1g-dev libyaml-dev libssl-dev libgdbm-dev libreadline-dev libncurses5-dev libffi-dev curl openssh-server checkinstall libxml2-dev libxslt-dev libcurl4-openssl-dev libicu-dev logrotate python-docutils pkg-config cmake
 
 If you want to use Kerberos for user authentication, then install libkrb5-dev:
 
@@ -151,13 +152,30 @@ page](https://golang.org/dl).
     sudo ln -sf /usr/local/go/bin/{go,godoc,gofmt} /usr/local/bin/
     rm go1.5.3.linux-amd64.tar.gz
 
-## 4. System Users
+## 4. Node
+
+Since GitLab 8.17, GitLab requires the use of node >= v4.3.0 to compile
+javascript assets, and starting in GitLab 9.0, yarn >= v0.17.0 is required to
+manage javascript dependencies. In many distros the versions provided by the
+official package repositories are out of date, so we'll need to install through
+the following commands:
+
+    # install node v7.x
+    curl --location https://deb.nodesource.com/setup_7.x | bash -
+    sudo apt-get install -y nodejs
+
+    # install yarn
+    curl --location https://yarnpkg.com/install.sh | bash -
+
+Visit the official websites for [node](https://nodejs.org/en/download/package-manager/) and [yarn](https://yarnpkg.com/en/docs/install/) if you have any trouble with these steps.
+
+## 5. System Users
 
 Create a `git` user for GitLab:
 
     sudo adduser --disabled-login --gecos 'GitLab' git
 
-## 5. Database
+## 6. Database
 
 We recommend using a PostgreSQL database. For MySQL check the
 [MySQL setup guide](database_mysql.md).
@@ -218,7 +236,7 @@ We recommend using a PostgreSQL database. For MySQL check the
     gitlabhq_production> \q
     ```
 
-## 6. Redis
+## 7. Redis
 
 GitLab requires at least Redis 2.8.
 
@@ -263,7 +281,7 @@ sudo service redis-server restart
 sudo usermod -aG redis git
 ```
 
-## 7. GitLab
+## 8. GitLab
 
     # We'll install GitLab into home directory of the user "git"
     cd /home/git
@@ -451,7 +469,8 @@ Check if GitLab and its environment are configured correctly:
 
 ### Compile Assets
 
-    sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
+    sudo -u git -H yarn install --production --pure-lockfile
+    sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production NODE_ENV=production
 
 ### Start Your GitLab Instance
 
@@ -459,7 +478,7 @@ Check if GitLab and its environment are configured correctly:
     # or
     sudo /etc/init.d/gitlab restart
 
-## 8. Nginx
+## 9. Nginx
 
 **Note:** Nginx is the officially supported web server for GitLab. If you cannot or do not want to use Nginx as your web server, have a look at the [GitLab recipes](https://gitlab.com/gitlab-org/gitlab-recipes/).
 
diff --git a/doc/profile/preferences.md b/doc/profile/preferences.md
index 073b8797508..4f2b00f3dd1 100644
--- a/doc/profile/preferences.md
+++ b/doc/profile/preferences.md
@@ -3,13 +3,6 @@
 Settings in the **Profile > Preferences** page allow the user to customize
 various aspects of the site to their liking.
 
-## Application theme
-
-Changing this setting allows the user to customize the color scheme used for the
-navigation bar on the left side of the screen.
-
-The default is **Charcoal**.
-
 ## Syntax highlighting theme
 
 _GitLab uses the [rouge ruby library][rouge] for syntax highlighting. For a
diff --git a/doc/university/README.md b/doc/university/README.md
index e9f14703789..8d4e7eff115 100644
--- a/doc/university/README.md
+++ b/doc/university/README.md
@@ -5,7 +5,7 @@ GitLab University is the best place to learn about **Version Control with Git an
 It doesn't replace, but accompanies our great [Documentation](https://docs.gitlab.com)
 and [Blog Articles](https://about.gitlab.com/blog/).
 
-Would you like to contribute to GitLab University? Then please take a look at our contribution [process](process) for more information.
+Would you like to contribute to GitLab University? Then please take a look at our contribution [process](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/PROCESS.md) for more information.
 
 ## Gitlab University Curriculum
 
diff --git a/doc/update/8.16-to-8.17.md b/doc/update/8.16-to-8.17.md
index 53c2bc560e8..954109ba18f 100644
--- a/doc/update/8.16-to-8.17.md
+++ b/doc/update/8.16-to-8.17.md
@@ -49,7 +49,19 @@ Install Bundler:
 sudo gem install bundler --no-ri --no-rdoc
 ```
 
-### 4. Get latest code
+### 4. Update Node
+
+GitLab now runs [webpack](http://webpack.js.org) to compile frontend assets and
+it has a minimum requirement of node v4.3.0.
+
+You can check which version you are running with `node -v`. If you are running
+a version older than `v4.3.0` you will need to update to a newer version.  You
+can find instructions to install from community maintained packages or compile
+from source at the nodejs.org website.
+
+<https://nodejs.org/en/download/>
+
+### 5. Get latest code
 
 ```bash
 cd /home/git/gitlab
@@ -76,7 +88,7 @@ cd /home/git/gitlab
 sudo -u git -H git checkout 8-17-stable-ee
 ```
 
-### 5. Install libs, migrations, etc.
+### 6. Install libs, migrations, etc.
 
 ```bash
 cd /home/git/gitlab
@@ -93,13 +105,16 @@ sudo -u git -H bundle clean
 # Run database migrations
 sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
 
+# Install/update frontend asset dependencies
+sudo -u git -H npm install --production
+
 # Clean up assets and cache
-sudo -u git -H bundle exec rake assets:clean assets:precompile cache:clear RAILS_ENV=production
+sudo -u git -H bundle exec rake gitlab:assets:clean gitlab:assets:compile cache:clear RAILS_ENV=production
 ```
 
 **MySQL installations**: Run through the `MySQL strings limits` and `Tables and data conversion to utf8mb4` [tasks](../install/database_mysql.md).
 
-### 6. Update gitlab-workhorse
+### 7. Update gitlab-workhorse
 
 Install and compile gitlab-workhorse. This requires
 [Go 1.5](https://golang.org/dl) which should already be on your system from
@@ -111,7 +126,7 @@ cd /home/git/gitlab
 sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production
 ```
 
-### 7. Update gitlab-shell
+### 8. Update gitlab-shell
 
 ```bash
 cd /home/git/gitlab-shell
@@ -120,7 +135,7 @@ sudo -u git -H git fetch --all --tags
 sudo -u git -H git checkout v4.1.1
 ```
 
-### 8. Update configuration files
+### 9. Update configuration files
 
 #### New configuration options for `gitlab.yml`
 
@@ -194,14 +209,14 @@ For Ubuntu 16.04.1 LTS:
 sudo systemctl daemon-reload
 ```
 
-### 9. Start application
+### 10. Start application
 
 ```bash
 sudo service gitlab start
 sudo service nginx restart
 ```
 
-### 10. Check application status
+### 11. Check application status
 
 Check if GitLab and its environment are configured correctly:
 
diff --git a/doc/user/project/integrations/img/services_templates_redmine_example.png b/doc/user/project/integrations/img/services_templates_redmine_example.png
index 50d20510daf..379cef9888d 100644
--- a/doc/user/project/integrations/img/services_templates_redmine_example.png
+++ b/doc/user/project/integrations/img/services_templates_redmine_example.png
diff --git a/doc/user/project/integrations/services_templates.md b/doc/user/project/integrations/services_templates.md
index be6d13b6d2b..5b04d7d88b8 100644
--- a/doc/user/project/integrations/services_templates.md
+++ b/doc/user/project/integrations/services_templates.md
@@ -1,25 +1,26 @@
-# Services Templates
+# Services templates
 
 A GitLab administrator can add a service template that sets a default for each
-project. This makes it much easier to configure individual projects.
+project. After a service template is enabled, it will be applied to new
+projects only and its details will be pre-filled on the project's Service page.
 
-After the template is created, the template details will be pre-filled on a
-project's Service page.
-
-## Enable a Service template
+## Enable a service template
 
 In GitLab's Admin area, navigate to **Service Templates** and choose the
 service template you wish to create.
 
-For example, in the image below you can see Redmine.
+## Services for external issue trackers
+
+In the image below you can see how a service template for Redmine would look
+like.
 
 ![Redmine service template](img/services_templates_redmine_example.png)
 
 ---
 
-**NOTE:** For each project, you will still need to configure the issue tracking
+For each project, you will still need to configure the issue tracking
 URLs by replacing `:issues_tracker_id` in the above screenshot with the ID used
 by your external issue tracker. Prior to GitLab v7.8, this ID was configured in
 the project settings, and GitLab would automatically update the URL configured
 in `gitlab.yml`. This behavior is now deprecated and all issue tracker URLs
-must be configured directly within the project's **Services** settings.
+must be configured directly within the project's **Integrations** settings.
diff --git a/doc/user/project/pipelines/settings.md b/doc/user/project/pipelines/settings.md
index 80cdb49a1d3..c398ac2eb25 100644
--- a/doc/user/project/pipelines/settings.md
+++ b/doc/user/project/pipelines/settings.md
@@ -62,9 +62,9 @@ pipelines** checkbox and save the changes.
 
 ## Badges
 
-In the pipelines settings page you can find job status and test coverage
+In the pipelines settings page you can find pipeline status and test coverage
 badges for your project. The latest successful pipeline will be used to read
-the job status and test coverage values.
+the pipeline status and test coverage values.
 
 Visit the pipelines settings page in your project to see the exact link to
 your badges, as well as ways to embed the badge image in your HTML or Markdown
@@ -72,7 +72,7 @@ pages.
 
 ![Pipelines badges](img/pipelines_settings_badges.png)
 
-### Job status badge
+### Pipeline status badge
 
 Depending on the status of your job, a badge can have the following values:
 
@@ -82,7 +82,7 @@ Depending on the status of your job, a badge can have the following values:
 - skipped
 - unknown
 
-You can access a job status badge image using the following link:
+You can access a pipeline status badge image using the following link:
 
 ```
 https://example.gitlab.com/<namespace>/<project>/badges/<branch>/build.svg
diff --git a/doc/workflow/gitlab_flow.md b/doc/workflow/gitlab_flow.md
index c228ea72f22..4889e3ec50c 100644
--- a/doc/workflow/gitlab_flow.md
+++ b/doc/workflow/gitlab_flow.md
@@ -67,7 +67,7 @@ With GitLab flow we offer additional guidance for these questions.
 ![Master branch and production branch with arrow that indicate deployments](production_branch.png)
 
 GitHub flow does assume you are able to deploy to production every time you merge a feature branch.
-This is possible for SaaS applications but are many cases where this is not possible.
+This is possible for SaaS applications but there are many cases where this is not possible.
 One would be a situation where you are not in control of the exact release moment, for example an iOS application that needs to pass App Store validation.
 Another example is when you have deployment windows (workdays from 10am to 4pm when the operations team is at full capacity) but you also merge code at other times.
 In these cases you can make a production branch that reflects the deployed code.
diff --git a/doc/workflow/todos.md b/doc/workflow/todos.md
index 99d7c18f072..6eb457fde3f 100644
--- a/doc/workflow/todos.md
+++ b/doc/workflow/todos.md
@@ -32,6 +32,29 @@ A Todo appears in your Todos dashboard when:
 
 >**Note:** Commenting on a commit will _not_ trigger a Todo.
 
+### Directly addressed Todos
+
+> [Introduced][ce-7926] in GitLab 9.0.
+
+If you are mentioned at the start of a line, the todo you receive will be listed
+as 'directly addressed'. For instance, in this comment:
+
+```markdown
+@alice What do you think? cc: @bob
+
+- @carol can you please have a look?
+
+>>>
+@dan what do you think?
+>>>
+
+@erin @frank thank you!
+```
+
+The people receiving directly addressed todos are `@alice`, `@erin`, and
+`@frank`. Directly addressed todos only differ from mention todos in their type,
+for filtering; otherwise, they appear as normal.
+
 ### Manually creating a Todo
 
 You can also add an issue or merge request to your Todos dashboard by clicking
@@ -85,8 +108,9 @@ There are four kinds of filters you can use on your Todos dashboard.
 | Project | Filter by project |
 | Author  | Filter by the author that triggered the Todo |
 | Type    | Filter by issue or merge request |
-| Action  | Filter by the action that triggered the Todo (Assigned or Mentioned)|
+| Action  | Filter by the action that triggered the Todo |
 
 You can also filter by more than one of these at the same time.
 
 [ce-2817]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2817
+[ce-7926]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7926