Merge remote-tracking branch 'origin/master' into 38759-fetch-available-parameters-directly-from-gke-when-creating-a-cluster

8 files changed, 518 insertions, 274 deletions

diff --git a/doc/development/README.md b/doc/development/README.md
index 3c77e99b8cf..898c60e96c0 100644
--- a/doc/development/README.md
+++ b/doc/development/README.md
@@ -1,5 +1,6 @@
 ---
 comments: false
+description: 'Learn how to contribute to GitLab.'
 ---
 
 # GitLab development guides
@@ -18,6 +19,7 @@ comments: false
 - [Code review guidelines](code_review.md) for reviewing code and having code reviewed.
 - [Automatic CE->EE merge](automatic_ce_ee_merge.md)
 - [Guidelines for implementing Enterprise Edition features](ee_features.md)
+- [Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer)
 
 ## UX and frontend guides
 
diff --git a/doc/development/doc_styleguide.md b/doc/development/doc_styleguide.md
index 5da015ca557..5d595c33915 100644
--- a/doc/development/doc_styleguide.md
+++ b/doc/development/doc_styleguide.md
@@ -1,3 +1,7 @@
+---
+description: 'Writing styles, markup, formatting, and reusing regular expressions throughout the GitLab Documentation.'
+---
+
 # Documentation style guidelines
 
 The documentation style guide defines the markup structure used in
@@ -21,23 +25,39 @@ Check the GitLab handbook for the [writing styles guidelines](https://about.gitl
 - Use [single spaces][] instead of double spaces
 - Jump a line between different markups (e.g., after every paragraph, header, list, etc)
 - Capitalize "G" and "L" in GitLab
-- Capitalize feature, products, and methods names. E.g.: GitLab Runner, Geo,
-Issue Boards, Git, Prometheus, Continuous Integration.
+- Use sentence case for titles, headings, labels, menu items, and buttons.
+- Use title case when referring to [features](https://about.gitlab.com/features/) or [products](https://about.gitlab.com/pricing/), and methods. Note that some features are also objects (e.g. "Merge Requests" and "merge requests"). E.g.: GitLab Runner, Geo, Issue Boards, Git, Prometheus, Continuous Integration.
 
 ## Formatting
 
+- Use double asterisks (`**`) to mark a word or text in bold (`**bold**`)
+- Use undescore (`_`) for text in italics (`_italic_`)
+- Jump a line between different markups, for example:
+
+    ```md
+    ## Header
+
+    Paragraph.
+
+    - List item
+    - List item
+    ```
+
+### Punctuation
+
+For punctuation rules, please refer to the [GitLab UX guide](https://design.gitlab.com/content/punctuation/).
+
+### Ordered and unordered lists
+
 - Use dashes (`-`) for unordered lists instead of asterisks (`*`)
 - Use the number one (`1`) for ordered lists
-- Use underscores (`_`) to mark a word or text in italics
-- Use double asterisks (`**`) to mark a word or text in bold
-- When using lists, prefer not to end each item with a period. You can use
-  them if there are multiple sentences, just keep the last sentence without
-  a period
+- For punctuation in bullet lists, please refer to the [GitLab UX guide](https://design.gitlab.com/content/punctuation/)
 
 ## Headings
 
-- Add only one H1 title in each document, by adding `#` at the beginning of
-  it (when using markdown). For subheadings, use `##`, `###` and so on
+- Add **only one H1** in each document, by adding `#` at the beginning of
+  it (when using markdown). The `h1` will be the document `<title>`.
+- For subheadings, use `##`, `###` and so on
 - Avoid putting numbers in headings. Numbers shift, hence documentation anchor
   links shift too, which eventually leads to dead links. If you think it is
   compelling to add numbers in headings, make sure to at least discuss it with
@@ -106,21 +126,75 @@ Inside the document:
 - If a heading is placed right after an image, always add three dashes (`---`)
   between the image and the heading
 
-## Notes
+## Alert boxes
 
-- Notes should be quoted with the word `Note:` being bold. Use this form:
+Whenever you want to call the attention to a particular sentence,
+use the following markup for highlighting.
 
-    ```md
-    >**Note:**
-    This is something to note.
-    ```
+_Note that the alert boxes only work for one paragraph only. Multiple paragraphs,
+lists, headers, etc will not render correctly._
+
+### Note
+
+```md
+NOTE: **Note:**
+This is something to note.
+```
+
+How it renders in docs.gitlab.com:
+
+NOTE: **Note:**
+This is something to note.
+
+### Tip
+
+```md
+TIP: **Tip:**
+This is a tip.
+```
+
+How it renders in docs.gitlab.com:
+
+TIP: **Tip:**
+This is a tip.
+
+### Caution
+
+```md
+CAUTION: **Caution:**
+This is something to be cautious about.
+```
+
+How it renders in docs.gitlab.com:
+
+CAUTION: **Caution:**
+This is something to be cautious about.
+
+### Danger
 
-    which renders to:
+```md
+DANGER: **Danger:**
+This is a breaking change, a bug, or something very important to note.
+```
+
+How it renders in docs.gitlab.com:
 
-    >**Note:**
-    This is something to note.
+DANGER: **Danger:**
+This is a breaking change, a bug, or something very important to note.
 
-    If the note spans across multiple lines it's OK to split the line.
+## Blockquotes
+
+For highlighting a text within a blue blockquote, use this format:
+
+```md
+> This is a blockquote.
+```
+
+which renders in docs.gitlab.com to:
+
+> This is a blockquote.
+
+If the text spans across multiple lines it's OK to split the line.
 
 ## Specific sections and terms
 
@@ -137,7 +211,7 @@ below.
     > Introduced in GitLab 8.3.
     ```
 
-- If possible every feature should have a link to the MR, issue, or epic that introduced it.
+- Whenever possible, every feature should have a link to the MR, issue, or epic that introduced it.
   The above note would be then transformed to:
 
     ```md
@@ -152,11 +226,9 @@ below.
   the feature is available in:
 
     ```md
-    > [Introduced][ee-1234] in [GitLab Starter](https://about.gitlab.com/products/) 8.3.
+    > [Introduced][ee-1234] in [GitLab Starter](https://about.gitlab.com/pricing/) 8.3.
     ```
 
-    Otherwise, leave this mention out.
-
 ### Product badges
 
 When a feature is available in EE-only tiers, add the corresponding tier according to the
diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md
index 3b4dfd50761..6d3796e7560 100644
--- a/doc/development/fe_guide/index.md
+++ b/doc/development/fe_guide/index.md
@@ -1,5 +1,8 @@
 # Frontend Development Guidelines
 
+> **Notice:**
+We are currently in the process of re-writing our development guide to make it easier to find information. The new guide is still WIP but viewable in [development/new_fe_guide](../new_fe_guide/index.md)
+
 This document describes various guidelines to ensure consistency and quality
 across GitLab's frontend team.
 
@@ -45,6 +48,9 @@ Common JavaScript design patterns in GitLab's codebase.
 ## [Vue.js Best Practices](vue.md)
 Vue specific design patterns and practices.
 
+## [Vuex](vuex.md)
+Vuex specific design patterns and practices.
+
 ## [Axios](axios.md)
 Axios specific practices and gotchas.
 
diff --git a/doc/development/fe_guide/style_guide_js.md b/doc/development/fe_guide/style_guide_js.md
index 677168937c7..04dfe418dbe 100644
--- a/doc/development/fe_guide/style_guide_js.md
+++ b/doc/development/fe_guide/style_guide_js.md
@@ -310,7 +310,7 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
     }));
   ```
 
-1. Don not use a singleton for the service or the store
+1. Do not use a singleton for the service or the store
   ```javascript
     // bad
     class Store {
@@ -328,9 +328,11 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
       }
     }
   ```
+1. Use `.vue` for Vue templates. Do not use `%template` in HAML.
 
 #### Naming
-1. **Extensions**: Use `.vue` extension for Vue components.
+
+1. **Extensions**: Use `.vue` extension for Vue components. Do not use `.js` as file extension ([#34371]).
 1. **Reference Naming**: Use PascalCase for their instances:
   ```javascript
     // bad
@@ -364,6 +366,8 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation.
     <component my-prop="prop" />
   ```
 
+[#34371]: https://gitlab.com/gitlab-org/gitlab-ce/issues/34371
+
 #### Alignment
 1. Follow these alignment styles for the template method:
   1. With more than one attribute, all attributes should be on a new line:
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 9c4b0e86351..f971d8b7388 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -1,29 +1,7 @@
 # Vue
 
-For more complex frontend features, we recommend using Vue.js. It shares
-some ideas with React.js as well as Angular.
-
 To get started with Vue, read through [their documentation][vue-docs].
 
-## When to use Vue.js
-
-We recommend using Vue for more complex features. Here are some guidelines for when to use Vue.js:
-
-- If you are starting a new feature or refactoring an old one that highly interacts with the DOM;
-- For real time data updates;
-- If you are creating a component that will be reused elsewhere;
-
-## When not to use Vue.js
-
-We don't want to refactor all GitLab frontend code into Vue.js, here are some guidelines for
-when not to use Vue.js:
-
-- Adding or changing static information;
-- Features that highly depend on jQuery will be hard to work with Vue.js;
-- Features without reactive data;
-
-As always, the Frontend Architectural Experts are available to help with any Vue or JavaScript questions.
-
 ## Vue architecture
 
 All new features built with Vue.js must follow a [Flux architecture][flux].
@@ -57,15 +35,15 @@ new_feature
 │   └── ...
 ├── stores
 │  └── new_feature_store.js
-├── services
+├── services # only when not using vuex
 │  └── new_feature_service.js
-├── new_feature_bundle.js
+├── index.js
 ```
 _For consistency purposes, we recommend you to follow the same structure._
 
 Let's look into each of them:
 
-### A `*_bundle.js` file
+### A `index.js` file
 
 This is the index file of your new feature. This is where the root Vue instance
 of the new feature should be.
@@ -144,30 +122,30 @@ in one table would not be a good use of this pattern.
 You can read more about components in Vue.js site, [Component System][component-system]
 
 #### Components Gotchas
-1. Using SVGs in components: To use an SVG in a template we need to make it a property we can access through the component.
-A `prop` and a property returned by the `data` functions require `vue` to set a `getter` and a `setter` for each of them.
-The SVG should be a computed property in order to improve performance, note that computed properties are cached based on their dependencies.
-
-```javascript
-// bad
-import svg from 'svg.svg';
-data() {
-  return {
-    myIcon: svg,
-  };
-};
-
-// good
-import svg from 'svg.svg';
-computed: {
-  myIcon() {
-    return svg;
-  }
-}
-```
+1. Using SVGs icons in components: To use an SVG icon in a template use the `icon.vue`
+1. Using SVGs illustrations in components: To use an SVG illustrations in a template provide the path as a prop and display it through a standard img tag.
+    ```javascript
+      <script>
+      export default {
+        props: {
+          svgIllustrationPath: {
+            type: String,
+            required: true,
+          },
+        },
+      };
+      <script>
+      <template>
+        <img :src="svgIllustrationPath" />
+      </template>
+    ```
 
 ### A folder for the Store
 
+#### Vuex
+Check this [page](vuex.md) for more details.
+
+#### Flux like state management
 The Store is a class that allows us to manage the state in a single
 source of truth. It is not aware of the service or the components.
 
@@ -176,6 +154,8 @@ itself, please read this guide: [State Management][state-management]
 
 ### A folder for the Service
 
+**If you are using Vuex you won't need this step**
+
 The Service is a class used only to communicate with the server.
 It does not store or manipulate any data. It is not aware of the store or the components.
 We use [axios][axios] to communicate with the server.
@@ -273,6 +253,9 @@ import Store from 'store';
 import Service from 'service';
 import TodoComponent from 'todoComponent';
 export default {
+  components: {
+    todo: TodoComponent,
+  },
   /**
    * 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
@@ -291,10 +274,6 @@ export default {
     };
   },
 
-  components: {
-    todo: TodoComponent,
-  },
-
   created() {
     this.service = new Service('todos');
 
@@ -476,201 +455,6 @@ need to test the rendered output. [Vue][vue-test] guide's to unit test show us e
 Refer to [mock axios](axios.md#mock-axios-response-on-tests)
 
 
-## Vuex
-To manage the state of an application you may use [Vuex][vuex-docs].
-
-_Note:_ All of the below is explained in more detail in the official [Vuex documentation][vuex-docs].
-
-### Separation of concerns
-Vuex is composed of State, Getters, Mutations, Actions and Modules.
-
-When a user clicks on an action, we need to `dispatch` it. This action will `commit` a mutation that will change the state.
-_Note:_ The action itself will not update the state, only a mutation should update the state.
-
-#### File structure
-When using Vuex at GitLab, separate this concerns into different files to improve readability. If you can, separate the Mutation Types as well:
-
-```
-└── store
-  ├── index.js          # where we assemble modules and export the store
-  ├── actions.js        # actions
-  ├── mutations.js      # mutations
-  ├── getters.js        # getters
-  └── mutation_types.js # mutation types
-```
-The following examples show an application that lists and adds users to the state.
-
-##### `index.js`
-This is the entry point for our store. You can use the following as a guide:
-
-```javascript
-import Vue from 'vue';
-import Vuex from 'vuex';
-import * as actions from './actions';
-import * as getters from './getters';
-import mutations from './mutations';
-
-Vue.use(Vuex);
-
-export default new Vuex.Store({
-  actions,
-  getters,
-  mutations,
-  state: {
-    users: [],
-  },
-});
-```
-_Note:_ If the state of the application is too complex, an individual file for the state may be better.
-
-##### `actions.js`
-An action commits a mutation. In this file, we will write the actions that will commit the respective mutation:
-
-```javascript
-  import * as types from './mutation_types';
-
-  export const addUser = ({ commit }, user) => {
-    commit(types.ADD_USER, user);
-  };
-```
-
-To dispatch an action from a component, use the `mapActions` helper:
-```javascript
-import { mapActions } from 'vuex';
-
-{
-  methods: {
-    ...mapActions([
-      'addUser',
-    ]),
-    onClickUser(user) {
-      this.addUser(user);
-    },
-  },
-};
-```
-
-##### `getters.js`
-Sometimes we may need to get derived state based on store state, like filtering for a specific prop. This can be done through the `getters`:
-
-```javascript
-// get all the users with pets
-export getUsersWithPets = (state, getters) => {
-  return state.users.filter(user => user.pet !== undefined);
-};
-```
-
-To access a getter from a component, use the `mapGetters` helper:
-```javascript
-import { mapGetters } from 'vuex';
-
-{
-  computed: {
-    ...mapGetters([
-      'getUsersWithPets',
-    ]),
-  },
-};
-```
-
-##### `mutations.js`
-The only way to actually change state in a Vuex store is by committing a mutation.
-
-```javascript
-  import * as types from './mutation_types';
-
-  export default {
-    [types.ADD_USER](state, user) {
-      state.users.push(user);
-    },
-  };
-```
-
-##### `mutations_types.js`
-From [vuex mutations docs][vuex-mutations]:
-> It is a commonly seen pattern to use constants for mutation types in various Flux implementations. This allows the code to take advantage of tooling like linters, and putting all constants in a single file allows your collaborators to get an at-a-glance view of what mutations are possible in the entire application.
-
-```javascript
-export const ADD_USER = 'ADD_USER';
-```
-
-### How to include the store in your application
-The store should be included in the main component of your application:
-```javascript
-  // app.vue
-  import store from 'store'; // it will include the index.js file
-
-  export default {
-    name: 'application',
-    store,
-    ...
-  };
-```
-
-### Vuex Gotchas
-1. Avoid calling a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency through out the application. From Vuex docs:
-
-  >  why don't we just call store.commit('action') directly? Well, remember that mutations must be synchronous? Actions aren't. We can perform asynchronous operations inside an action.
-
-  ```javascript
-    // component.vue
-
-    // bad
-    created() {
-      this.$store.commit('mutation');
-    }
-
-    // good
-    created() {
-      this.$store.dispatch('action');
-    }
-  ```
-1. When possible, use mutation types instead of hardcoding strings. It will be less error prone.
-1. The State will be accessible in all components descending from the use where the store is instantiated.
-
-### Testing Vuex
-#### Testing Vuex concerns
-Refer to [vuex docs][vuex-testing] regarding testing Actions, Getters and Mutations.
-
-#### Testing components that need a store
-Smaller components might use `store` properties to access the data.
-In order to write unit tests for those components, we need to include the store and provide the correct state:
-
-```javascript
-//component_spec.js
-import Vue from 'vue';
-import store from './store';
-import component from './component.vue'
-
-describe('component', () => {
-  let vm;
-  let Component;
-
-  beforeEach(() => {
-    Component = Vue.extend(issueActions);
-  });
-
-  afterEach(() => {
-    vm.$destroy();
-  });
-
-  it('should show a user', () => {
-    const user = {
-      name: 'Foo',
-      age: '30',
-    };
-
-    // populate the store
-    store.dispatch('addUser', user);
-
-    vm = new Component({
-      store,
-      propsData: props,
-    }).$mount();
-  });
-});
-```
-
 [vue-docs]: http://vuejs.org/guide/index.html
 [issue-boards]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/boards
 [environments-table]: https://gitlab.com/gitlab-org/gitlab-ce/tree/master/app/assets/javascripts/environments
@@ -681,9 +465,5 @@ describe('component', () => {
 [vue-test]: https://vuejs.org/v2/guide/unit-testing.html
 [issue-boards-service]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/boards/services/board_service.js.es6
 [flux]: https://facebook.github.io/flux
-[vuex-docs]: https://vuex.vuejs.org
-[vuex-structure]: https://vuex.vuejs.org/en/structure.html
-[vuex-mutations]: https://vuex.vuejs.org/en/mutations.html
-[vuex-testing]: https://vuex.vuejs.org/en/testing.html
 [axios]: https://github.com/axios/axios
 [axios-interceptors]: https://github.com/axios/axios#interceptors
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
new file mode 100644
index 00000000000..6a89bfc7721
--- /dev/null
+++ b/doc/development/fe_guide/vuex.md
@@ -0,0 +1,358 @@
+# Vuex
+To manage the state of an application you should use [Vuex][vuex-docs].
+
+_Note:_ All of the below is explained in more detail in the official [Vuex documentation][vuex-docs].
+
+## Separation of concerns
+Vuex is composed of State, Getters, Mutations, Actions and Modules.
+
+When a user clicks on an action, we need to `dispatch` it. This action will `commit` a mutation that will change the state.
+_Note:_ The action itself will not update the state, only a mutation should update the state.
+
+## File structure
+When using Vuex at GitLab, separate this concerns into different files to improve readability:
+
+```
+└── store
+  ├── index.js          # where we assemble modules and export the store
+  ├── actions.js        # actions
+  ├── mutations.js      # mutations
+  ├── getters.js        # getters
+  ├── state.js          # state
+  └── mutation_types.js # mutation types
+```
+The following example shows an application that lists and adds users to the state.
+(For a more complex example implementation take a look at the security applications store in [here](https://gitlab.com/gitlab-org/gitlab-ee/tree/master/ee/app/assets/javascripts/vue_shared/security_reports/store))
+
+### `index.js`
+This is the entry point for our store. You can use the following as a guide:
+
+```javascript
+import Vue from 'vue';
+import Vuex from 'vuex';
+import * as actions from './actions';
+import * as getters from './getters';
+import mutations from './mutations';
+import state from './state';
+
+Vue.use(Vuex);
+
+export default new Vuex.Store({
+  actions,
+  getters,
+  mutations,
+  state,
+});
+```
+
+### `state.js`
+The first thing you should do before writing any code is to design the state.
+
+Often we need to provide data from haml to our Vue application. Let's store it in the state for better access.
+
+```javascript
+  export default {
+    endpoint: null,
+
+    isLoading: false,
+    error: null,
+
+    isAddingUser: false,
+    errorAddingUser: false,
+
+    users: [],
+  };
+```
+
+#### Access `state` properties
+You can use `mapState` to access state properties in the components.
+
+### `actions.js`
+An action is a playload of information to send data from our application to our store.
+
+An action is usually composed by a `type` and a `payload` and they describe what happened.
+Enforcing that every change is described as an action lets us have a clear understanting of what is going on in the app.
+
+In this file, we will write the actions that will call the respective mutations:
+
+```javascript
+  import * as types from './mutation_types';
+  import axios from '~/lib/utils/axios-utils';
+  import createFlash from '~/flash';
+
+  export const requestUsers = ({ commit }) => commit(types.REQUEST_USERS);
+  export const receiveUsersSuccess = ({ commit }, data) => commit(types.RECEIVE_USERS_SUCCESS, data);
+  export const receiveUsersError = ({ commit }, error) => commit(types.REQUEST_USERS_ERROR, error);
+
+  export const fetchUsers = ({ state, dispatch }) => {
+    dispatch('requestUsers');
+
+    axios.get(state.endoint)
+      .then(({ data }) => dispatch('receiveUsersSuccess', data))
+      .catch((error) => {
+        dispatch('receiveUsersError', error)
+        createFlash('There was an error')
+      });
+  }
+
+  export const requestAddUser = ({ commit }) => commit(types.REQUEST_ADD_USER);
+  export const receiveAddUserSuccess = ({ commit }, data) => commit(types.RECEIVE_ADD_USER_SUCCESS, data);
+  export const receiveAddUserError = ({ commit }, error) => commit(types.REQUEST_ADD_USER_ERROR, error);
+
+  export const addUser = ({ state, dispatch }, user) => {
+    dispatch('requestAddUser');
+
+    axios.post(state.endoint, user)
+      .then(({ data }) => dispatch('receiveAddUserSuccess', data))
+      .catch((error) => dispatch('receiveAddUserError', error));
+  }
+```
+
+#### Actions Pattern: `request` and `receive` namespaces
+When a request is made we often want to show a loading state to the user.
+
+Instead of creating an action to toggle the loading state and dispatch it in the component,
+create:
+1. An action `requestSomething`, to toggle the loading state
+1. An action `receiveSomethingSuccess`, to handle the success callback
+1. An action `receiveSomethingError`, to handle the error callback
+1. An action `fetchSomething` to make the request.
+    1. In case your application does more than a `GET` request you can use these as examples:
+        1. `PUT`: `createSomething`
+        2. `POST`: `updateSomething`
+        3. `DELETE`: `deleteSomething`
+
+The component MUST only dispatch the `fetchNamespace` action. Actions namespaced with `request` or `receive` should not be called from the component
+The `fetch` action will be responsible to dispatch `requestNamespace`, `receiveNamespaceSuccess` and `receiveNamespaceError`
+
+By following this pattern we guarantee:
+1. All aplications follow the same pattern, making it easier for anyone to maintain the code
+1. All data in the application follows the same lifecycle pattern
+1. Actions are contained and human friendly
+1. Unit tests are easier
+1. Actions are simple and straightforward
+
+#### Dispatching actions
+To dispatch an action from a component, use the `mapActions` helper:
+```javascript
+import { mapActions } from 'vuex';
+
+{
+  methods: {
+    ...mapActions([
+      'addUser',
+    ]),
+    onClickUser(user) {
+      this.addUser(user);
+    },
+  },
+};
+```
+
+#### `mutations.js`
+The mutations specify how the application state changes in response to actions sent to the store.
+The only way to change state in a Vuex store should be by committing a mutation.
+
+**It's a good idea to think of the state before writing any code.**
+
+Remember that actions only describe that something happened, they don't describe how the application state changes.
+
+**Never commit a mutation directly from a component**
+
+```javascript
+  import * as types from './mutation_types';
+
+  export default {
+    [types.REQUEST_USERS](state) {
+      state.isLoading = true;
+    },
+    [types.RECEIVE_USERS_SUCCESS](state, data) {
+      // Do any needed data transformation to the received payload here
+      state.users = data;
+      state.isLoading = false;
+    },
+    [types.REQUEST_USERS_ERROR](state, error) {
+      state.isLoading = false;
+    },
+    [types.REQUEST_ADD_USER](state, user) {
+     state.isAddingUser = true;
+    },
+    [types.RECEIVE_ADD_USER_SUCCESS](state, user) {
+      state.isAddingUser = false;
+      state.users.push(user);
+    },
+    [types.REQUEST_ADD_USER_ERROR](state, error) {
+      state.isAddingUser = true;
+      state.errorAddingUser = error∂;
+    },
+  };
+```
+
+#### `getters.js`
+Sometimes we may need to get derived state based on store state, like filtering for a specific prop.
+Using a getter will also cache the result based on dependencies due to [how computed props work](https://vuejs.org/v2/guide/computed.html#Computed-Caching-vs-Methods)
+This can be done through the `getters`:
+
+```javascript
+// get all the users with pets
+export const getUsersWithPets = (state, getters) => {
+  return state.users.filter(user => user.pet !== undefined);
+};
+```
+
+To access a getter from a component, use the `mapGetters` helper:
+```javascript
+import { mapGetters } from 'vuex';
+
+{
+  computed: {
+    ...mapGetters([
+      'getUsersWithPets',
+    ]),
+  },
+};
+```
+
+#### `mutations_types.js`
+From [vuex mutations docs][vuex-mutations]:
+> It is a commonly seen pattern to use constants for mutation types in various Flux implementations. This allows the code to take advantage of tooling like linters, and putting all constants in a single file allows your collaborators to get an at-a-glance view of what mutations are possible in the entire application.
+
+```javascript
+export const ADD_USER = 'ADD_USER';
+```
+
+### How to include the store in your application
+The store should be included in the main component of your application:
+```javascript
+  // app.vue
+  import store from 'store'; // it will include the index.js file
+
+  export default {
+    name: 'application',
+    store,
+    ...
+  };
+```
+
+### Communicating with the Store
+```javascript
+<script>
+import { mapActions, mapState, mapGetters } from 'vuex';
+import store from './store';
+
+export default {
+  store,
+  computed: {
+    ...mapGetters([
+      'getUsersWithPets'
+    ]),
+    ...mapState([
+      'isLoading',
+      'users',
+      'error',
+    ]),
+  },
+  methods: {
+    ...mapActions([
+      'fetchUsers',
+      'addUser',
+    ]),
+
+    onClickAddUser(data) {
+      this.addUser(data);
+    }
+  },
+
+  created() {
+    this.fetchUsers()
+  }
+}
+</script>
+<template>
+  <ul>
+    <li v-if="isLoading">
+      Loading...
+    </li>
+    <li v-else-if="error">
+      {{ error }}
+    </li>
+    <template v-else>
+      <li
+        v-for="user in users"
+        :key="user.id"
+      >
+        {{ user }}
+      </li>
+    </template>
+  </ul>
+</template>
+```
+
+### Vuex Gotchas
+1. Do not call a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency through out the application. From Vuex docs:
+
+  >  why don't we just call store.commit('action') directly? Well, remember that mutations must be synchronous? Actions aren't. We can perform asynchronous operations inside an action.
+
+  ```javascript
+    // component.vue
+
+    // bad
+    created() {
+      this.$store.commit('mutation');
+    }
+
+    // good
+    created() {
+      this.$store.dispatch('action');
+    }
+  ```
+1. Use mutation types instead of hardcoding strings. It will be less error prone.
+1. The State will be accessible in all components descending from the use where the store is instantiated.
+
+### Testing Vuex
+#### Testing Vuex concerns
+Refer to [vuex docs][vuex-testing] regarding testing Actions, Getters and Mutations.
+
+#### Testing components that need a store
+Smaller components might use `store` properties to access the data.
+In order to write unit tests for those components, we need to include the store and provide the correct state:
+
+```javascript
+//component_spec.js
+import Vue from 'vue';
+import store from './store';
+import component from './component.vue'
+
+describe('component', () => {
+  let vm;
+  let Component;
+
+  beforeEach(() => {
+    Component = Vue.extend(issueActions);
+  });
+
+  afterEach(() => {
+    vm.$destroy();
+  });
+
+  it('should show a user', () => {
+    const user = {
+      name: 'Foo',
+      age: '30',
+    };
+
+    // populate the store
+    store.dipatch('addUser', user);
+
+    vm = new Component({
+      store,
+      propsData: props,
+    }).$mount();
+  });
+});
+```
+
+[vuex-docs]: https://vuex.vuejs.org
+[vuex-structure]: https://vuex.vuejs.org/en/structure.html
+[vuex-mutations]: https://vuex.vuejs.org/en/mutations.html
+[vuex-testing]: https://vuex.vuejs.org/en/testing.html
diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md
index 7b32e0a47e1..61fa5459b91 100644
--- a/doc/development/testing_guide/best_practices.md
+++ b/doc/development/testing_guide/best_practices.md
@@ -230,6 +230,11 @@ describe "#==" do
 end
 ```
 
+### Prometheus tests
+
+Prometheus metrics may be preserved from one test run to another. To ensure that metrics are
+reset before each example, add the `:prometheus` tag to the Rspec test.
+
 ### Matchers
 
 Custom matchers should be created to clarify the intent and/or hide the
diff --git a/doc/development/writing_documentation.md b/doc/development/writing_documentation.md
index 9bca4637830..1c41fc7611f 100644
--- a/doc/development/writing_documentation.md
+++ b/doc/development/writing_documentation.md
@@ -1,3 +1,7 @@
+---
+description: Learn how to contribute to GitLab Documentation.
+---
+
 # GitLab Documentation guidelines
 
   - **General Documentation**: written by the [developers responsible by creating features](#contributing-to-docs). Should be submitted in the same merge request containing code. Feature proposals (by GitLab contributors) should also be accompanied by its respective documentation. They can be later improved by PMs and Technical Writers.
@@ -201,6 +205,19 @@ Things to note:
   built-in help page, that's why we omit it in `git grep`.
 - Use the checklist on the documentation MR description template.
 
+#### Alternative redirection method
+
+Alternatively to the method described above, you can simply replace the content
+of the old file with a frontmatter containing a redirect link:
+
+```yaml
+---
+redirect_to: '../path/to/file/README.md'
+---
+```
+
+It supports both full and relative URLs, e.g. `https://docs.gitlab.com/ee/path/to/file.html`, `../path/to/file.html`, `path/to/file.md`. Note that any `*.md` paths will be compiled to `*.html`.
+
 ### Redirections for pages with Disqus comments
 
 If the documentation page being relocated already has any Disqus comments,