9 files changed, 152 insertions, 58 deletions
diff --git a/doc/administration/high_availability/redis_source.md b/doc/administration/high_availability/redis_source.md
index fe982ea83c2..8b7a515a076 100644
--- a/doc/administration/high_availability/redis_source.md
+++ b/doc/administration/high_availability/redis_source.md
@@ -4,6 +4,11 @@ This is the documentation for configuring a Highly Available Redis setup when
 you have installed Redis all by yourself and not using the bundled one that
 comes with the Omnibus packages.
 
+Note also that you may elect to override all references to
+`/home/git/gitlab/config/resque.yml` in accordance with the advanced Redis
+settings outlined in
+[Configuration Files Documentation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/README.md).
+
 We cannot stress enough the importance of reading the
 [Overview section](redis.md#overview) of the Omnibus Redis HA as it provides
 some invaluable information to the configuration of Redis. Please proceed to
diff --git a/doc/administration/operations/cleaning_up_redis_sessions.md b/doc/administration/operations/cleaning_up_redis_sessions.md
index 93521e976d5..3a35aff8366 100644
--- a/doc/administration/operations/cleaning_up_redis_sessions.md
+++ b/doc/administration/operations/cleaning_up_redis_sessions.md
@@ -15,6 +15,12 @@ prefixed with 'session:gitlab:', so they would look like
 'session:gitlab:976aa289e2189b17d7ef525a6702ace9'. Below we describe how to
 remove the keys in the old format.
 
+**Note:** the instructions below must be modified in accordance with your
+configuration settings if you have used the advanced Redis
+settings outlined in
+[Configuration Files Documentation](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/config/README.md).
+
+
 First we define a shell function with the proper Redis connection details.
 
 ```
diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md
index 3dc808c196d..c90d95e4dd0 100644
--- a/doc/api/merge_requests.md
+++ b/doc/api/merge_requests.md
@@ -25,6 +25,7 @@ Parameters:
 | `order_by`| string  | no    | Return requests ordered by `created_at` or `updated_at` fields. Default is `created_at` |
 | `sort`    | string  | no    | Return requests sorted in `asc` or `desc` order. Default is `desc`  |
 | `milestone`  | string  | no | Return merge requests for a specific milestone |
+| `view` | string | no | If `simple`, returns the `iid`, URL, title, description, and basic state of merge request |
 | `labels`  | string  | no | Return merge requests matching a comma separated list of labels |
 | `created_after` | datetime | no | Return merge requests created after the given time (inclusive) |
 | `created_before` | datetime | no | Return merge requests created before the given time (inclusive) |
diff --git a/doc/api/users.md b/doc/api/users.md
index 91170e79645..6e5ec3231c5 100644
--- a/doc/api/users.md
+++ b/doc/api/users.md
@@ -364,7 +364,7 @@ GET /user
 
 Parameters:
 
-- `sudo` (required) - the ID of a user
+- `sudo` (optional) - the ID of a user to make the call in their place
 
 ```
 GET /user
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index a984bb6c94c..0742b202807 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -112,7 +112,50 @@ Vue Resource should only be imported in the service file.
   Vue.use(VueResource);
   ```
 
-### CSRF token
+#### Vue-resource gotchas
+#### Headers
+Headers are being parsed into a plain object in an interceptor.
+In Vue-resource 1.x `headers` object was changed into an `Headers` object. In order to not change all old code, an interceptor was added.
+
+If you need to write a unit test that takes the headers in consideration, you need to include an interceptor to parse the headers after your test interceptor.
+You can see an example in `spec/javascripts/environments/environment_spec.js`:
+  ```javascript
+  import { headersInterceptor } from './helpers/vue_resource_helper';
+
+  beforeEach(() => {
+    Vue.http.interceptors.push(myInterceptor);
+    Vue.http.interceptors.push(headersInterceptor);
+  });
+
+  afterEach(() => {
+    Vue.http.interceptors = _.without(Vue.http.interceptors, myInterceptor);
+    Vue.http.interceptors = _.without(Vue.http.interceptors, headersInterceptor);
+  });
+  ```
+
+#### `.json()`
+When making a request to the server, you will most likely need to access the body of the response.
+Use `.json()` to convert. Because `.json()` returns a Promise the follwoing structure should be used:
+
+  ```javascript
+  service.get('url')
+    .then(resp => resp.json())
+    .then((data) => {
+      this.store.storeData(data);
+    })
+    .catch(() => new Flash('Something went wrong'));
+  ```
+
+When using `Poll` (`app/assets/javascripts/lib/utils/poll.js`), the `successCallback` needs to handle `.json()` as a Promise:
+  ```javascript
+  successCallback: (response) => {
+    return response.json().then((data) => {
+      // handle the response
+    });
+  }
+  ```
+
+#### CSRF token
 We use a Vue Resource interceptor to manage the CSRF token.
 `app/assets/javascripts/vue_shared/vue_resource_interceptor.js` holds all our common interceptors.
 Note: You don't need to load `app/assets/javascripts/vue_shared/vue_resource_interceptor.js`
@@ -126,13 +169,13 @@ The following example shows an  application:
 // store.js
 export default class Store {
 
-  /**  
+  /**
    * This is where we will iniatialize the state of our data.
    * Usually in a small SPA you don't need any options when starting the store. In the case you do
    * need guarantee it's an Object and it's documented.
-   *    
-   * @param  {Object} options   
-   */   
+   *
+   * @param  {Object} options
+   */
   constructor(options) {
     this.options = options;
 
@@ -205,14 +248,14 @@ import Store from 'store';
 import Service from 'service';
 import TodoComponent from 'todoComponent';
 export default {
-  /**  
+  /**
    * Although most data belongs in the store, each component it's own state.
    * We want to show a loading spinner while we are fetching the todos, this state belong
    * in the component.
    *
    * We need to access the store methods through all methods of our component.
    * We need to access the state of our store.
-   */   
+   */
   data() {
     const store = new Store();
 
@@ -396,42 +439,46 @@ need to test the rendered output. [Vue][vue-test] guide's to unit test show us e
 [Vue Resource Interceptors][vue-resource-interceptor] allow us to add a interceptor with
 the response we need:
 
-```javascript
-  // Mock the service to return data
-  const interceptor = (request, next) => {
-    next(request.respondWith(JSON.stringify([{
-      title: 'This is a todo',
-      body: 'This is the text'
-    }]), {
-      status: 200,
-    }));
-  };
+  ```javascript
+    // Mock the service to return data
+    const interceptor = (request, next) => {
+      next(request.respondWith(JSON.stringify([{
+        title: 'This is a todo',
+        body: 'This is the text'
+      }]), {
+        status: 200,
+      }));
+    };
 
-  beforeEach(() => {
-    Vue.http.interceptors.push(interceptor);
-  });
+    beforeEach(() => {
+      Vue.http.interceptors.push(interceptor);
+    });
 
-  afterEach(() => {
-    Vue.http.interceptors = _.without(Vue.http.interceptors, interceptor);
-  });
+    afterEach(() => {
+      Vue.http.interceptors = _.without(Vue.http.interceptors, interceptor);
+    });
 
-  it('should do something', (done) => {
-    setTimeout(() => {
-      // Test received data
-      done();
-    }, 0);
-  });
-```
+    it('should do something', (done) => {
+      setTimeout(() => {
+        // Test received data
+        done();
+      }, 0);
+    });
+  ```
+
+1. Headers interceptor
+Refer to [this section](vue.md#headers)
 
 1. Use `$.mount()` to mount the component
+
 ```javascript
-  // bad
-  new Component({
-    el: document.createElement('div')
-  });
+// bad
+new Component({
+  el: document.createElement('div')
+});
 
-  // good
-  new Component().$mount();
+// good
+new Component().$mount();
 ```
 
 [vue-docs]: http://vuejs.org/guide/index.html
diff --git a/doc/install/installation.md b/doc/install/installation.md
index dfa25deb961..5e981b0b3e7 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -294,9 +294,9 @@ sudo usermod -aG redis git
 ### Clone the Source
 
     # Clone GitLab repository
-    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 9-3-stable gitlab
+    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 9-4-stable gitlab
 
-**Note:** You can change `9-3-stable` to `master` if you want the *bleeding edge* version, but never install master on a production server!
+**Note:** You can change `9-4-stable` to `master` if you want the *bleeding edge* version, but never install master on a production server!
 
 ### Configure It
 
diff --git a/doc/install/requirements.md b/doc/install/requirements.md
index a3d676433e6..141df55f6bc 100644
--- a/doc/install/requirements.md
+++ b/doc/install/requirements.md
@@ -69,7 +69,7 @@ so keep in mind that you need at least 4GB available before running GitLab. With
 less memory GitLab will give strange errors during the reconfigure run and 500
 errors during usage.
 
-- 1GB RAM + 3GB of swap is the absolute minimum but we strongly **advise against** this amount of memory. See the unicorn worker section below for more advice.
+- 1GB RAM + 3GB of swap is the absolute minimum but we strongly **advise against** this amount of memory. See the [unicorn worker section below](#unicorn-workers) for more advice.
 - 2GB RAM + 2GB swap supports up to 100 users but it will be very slow
 - **4GB RAM** is the **recommended** memory size for all installations and supports up to 100 users
 - 8GB RAM supports up to 1,000 users
diff --git a/doc/update/9.3-to-9.4.md b/doc/update/9.3-to-9.4.md
index bbb7f4a8d48..6962d124c80 100644
--- a/doc/update/9.3-to-9.4.md
+++ b/doc/update/9.3-to-9.4.md
@@ -72,8 +72,8 @@ More information can be found on the [yarn website](https://yarnpkg.com/en/docs/
 
 ### 5. Update Go
 
-NOTE: GitLab 9.4 and higher only supports Go 1.8.3 and dropped support for Go 1.5.x through 1.7.x. Be
-sure to upgrade your installation if necessary
+NOTE: GitLab 9.2 and higher only supports Go 1.8.3 and dropped support for Go
+1.5.x through 1.7.x. Be sure to upgrade your installation if necessary.
 
 You can check which version you are running with `go version`.
 
@@ -117,7 +117,7 @@ cd /home/git/gitlab
 sudo -u git -H git checkout 9-4-stable-ee
 ```
 
-### 5. Update gitlab-shell
+### 7. Update gitlab-shell
 
 ```bash
 cd /home/git/gitlab-shell
@@ -127,11 +127,10 @@ sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_SHELL_VERSION)
 sudo -u git -H bin/compile
 ```
 
-### 6. Update gitlab-workhorse
+### 8. Update gitlab-workhorse
 
-Install and compile gitlab-workhorse. This requires
-[Go 1.8](https://golang.org/dl) which should already be on your system from
-GitLab 8.1. GitLab-Workhorse uses [GNU Make](https://www.gnu.org/software/make/).
+Install and compile gitlab-workhorse. GitLab-Workhorse uses
+[GNU Make](https://www.gnu.org/software/make/).
 If you are not using Linux you may have to run `gmake` instead of
 `make` below.
 
@@ -143,7 +142,7 @@ sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_WORKHORSE_VERSION)
 sudo -u git -H make
 ```
 
-### 7. Update Gitaly
+### 9. Update Gitaly
 
 If you have not yet set up Gitaly then follow [Gitaly section of the installation
 guide](../install/installation.md#install-gitaly).
@@ -171,7 +170,29 @@ sudo -u git -H git checkout v$(</home/git/gitlab/GITALY_SERVER_VERSION)
 sudo -u git -H make
 ```
 
-### 10. Update configuration files
+### 10. Update MySQL permissions
+
+If you are using MySQL you need to grant the GitLab user the necessary
+permissions on the database:
+
+```bash
+mysql -u root -p -e "GRANT TRIGGER ON \`gitlabhq_production\`.* TO 'git'@'localhost';"
+```
+
+If you use MySQL with replication, or just have MySQL configured with binary logging,
+you will need to also run the following on all of your MySQL servers:
+
+```bash
+mysql -u root -p -e "SET GLOBAL log_bin_trust_function_creators = 1;"
+```
+
+You can make this setting permanent by adding it to your `my.cnf`:
+
+```
+log_bin_trust_function_creators=1
+```
+
+### 11. Update configuration files
 
 #### New configuration options for `gitlab.yml`
 
@@ -245,7 +266,7 @@ For Ubuntu 16.04.1 LTS:
 sudo systemctl daemon-reload
 ```
 
-### 11. Install libs, migrations, etc.
+### 12. Install libs, migrations, etc.
 
 ```bash
 cd /home/git/gitlab
@@ -271,14 +292,14 @@ sudo -u git -H bundle exec rake 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).
 
-### 12. Start application
+### 13. Start application
 
 ```bash
 sudo service gitlab start
 sudo service nginx restart
 ```
 
-### 13. Check application status
+### 14. Check application status
 
 Check if GitLab and its environment are configured correctly:
 
diff --git a/doc/user/admin_area/monitoring/health_check.md b/doc/user/admin_area/monitoring/health_check.md
index a954840b8a6..69a9dfc3500 100644
--- a/doc/user/admin_area/monitoring/health_check.md
+++ b/doc/user/admin_area/monitoring/health_check.md
@@ -5,6 +5,8 @@
   - The `health_check` endpoint was [introduced][ce-3888] in GitLab 8.8 and will
     be deprecated in GitLab 9.1. Read more in the [old behavior](#old-behavior)
     section.
+  - [Access token](#access-token) has been deprecated in GitLab 9.4
+    in favor of [IP Whitelist](#ip-whitelist)
 
 GitLab provides liveness and readiness probes to indicate service health and
 reachability to required services. These probes report on the status of the
@@ -12,7 +14,19 @@ database connection, Redis connection, and access to the filesystem. These
 endpoints [can be provided to schedulers like Kubernetes][kubernetes] to hold
 traffic until the system is ready or restart the container as needed.
 
-## Access Token
+## IP Whitelist
+
+To access monitoring resources the client IP needs to be included in the whitelist.
+To add or remove hosts or IP ranges from the list you can edit `gitlab.rb` or `gitlab.yml`.
+
+Example whitelist configuration:
+```yaml
+monitoring:
+  ip_whitelist:
+    - 127.0.0.0/8 # by default only local IPs are allowed to access monitoring resources
+```
+
+## Access Token (Deprecated)
 
 An access token needs to be provided while accessing the probe endpoints. The current
 accepted token can be found under the **Admin area ➔ Monitoring ➔ Health check**
@@ -47,10 +61,10 @@ which will then provide a report of system health in JSON format:
 
 ## Using the Endpoint
 
-Once you have the access token, the probes can be accessed:
+With default whitelist settings, the probes can be accessed from localhost:
 
-- `https://gitlab.example.com/-/readiness?token=ACCESS_TOKEN`
-- `https://gitlab.example.com/-/liveness?token=ACCESS_TOKEN`
+- `http://localhost/-/readiness`
+- `http://localhost/-/liveness`
 
 ## Status
 
@@ -71,8 +85,8 @@ the database connection, the state of the database migrations, and the ability t
 and access the cache. This endpoint can be provided to uptime monitoring services like
 [Pingdom][pingdom], [Nagios][nagios-health], and [NewRelic][newrelic-health].
 
-Once you have the [access token](#access-token), health information can be
-retrieved as plain text, JSON, or XML using the `health_check` endpoint:
+Once you have the [access token](#access-token) or your client IP is [whitelisted](#ip-whitelist),
+health information can be retrieved as plain text, JSON, or XML using the `health_check` endpoint:
 
 - `https://gitlab.example.com/health_check?token=ACCESS_TOKEN`
 - `https://gitlab.example.com/health_check.json?token=ACCESS_TOKEN`