Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/boards/components/board_blank_state.vue

@@ -29,25 +29,25 @@ export default {
         });
       });
+      const loadListIssues = listObj => {
+        const list = boardsStore.findList('title', listObj.title);
+
+        if (!list) {
+          return null;
+        }
+
+        list.id = listObj.id;
+        list.label.id = listObj.label.id;
+        return list.getIssues().catch(() => {
+          // TODO: handle request error
+        });
+      };
+
       // Save the labels
       boardsStore
         .generateDefaultLists()
         .then(res => res.data)
-        .then(data => {
-          data.forEach(listObj => {
-            const list = boardsStore.findList('title', listObj.title);
-
-            if (!list) {
-              return;
-            }
-
-            list.id = listObj.id;
-            list.label.id = listObj.label.id;
-            list.getIssues().catch(() => {
-              // TODO: handle request error
-            });
-          });
-        })
+        .then(data => Promise.all(data.map(loadListIssues)))
         .catch(() => {
           boardsStore.removeList(undefined, 'label');
           Cookies.remove('issue_board_welcome_hidden', {

app/assets/javascripts/notes/stores/actions.js

@@ -251,58 +251,80 @@ export const saveNote = ({ commit, dispatch }, noteData) => {
     }
   }
-  return dispatch(methodToDispatch, postData, { root: true }).then(res => {
+  const processErrors = res => {
     const { errors } = res;
-    const commandsChanges = res.commands_changes;
-    if (errors && Object.keys(errors).length) {
-      /*
-       The following reply means that quick actions have been successfully applied:
-       {"commands_changes":{},"valid":false,"errors":{"commands_only":["Commands applied"]}}
-       */
-      if (hasQuickActions) {
-        eTagPoll.makeRequest();
-        $('.js-gfm-input').trigger('clear-commands-cache.atwho');
-        Flash(__('Commands applied'), 'notice', noteData.flashContainer);
-      } else {
-        throw new Error(__('Failed to save comment!'));
-      }
+    if (!errors || !Object.keys(errors).length) {
+      return res;
+    }
+    /*
+     The following reply means that quick actions have been successfully applied:
+     {"commands_changes":{},"valid":false,"errors":{"commands_only":["Commands applied"]}}
+     */
+    if (hasQuickActions) {
+      eTagPoll.makeRequest();
+      $('.js-gfm-input').trigger('clear-commands-cache.atwho');
+
+      const { commands_only: message } = errors;
+      Flash(message || __('Commands applied'), 'notice', noteData.flashContainer);
+
+      return res;
     }
-    if (commandsChanges) {
-      if (commandsChanges.emoji_award) {
-        const votesBlock = $('.js-awards-block').eq(0);
-
-        loadAwardsHandler()
-          .then(awardsHandler => {
-            awardsHandler.addAwardToEmojiBar(votesBlock, commandsChanges.emoji_award);
-            awardsHandler.scrollToAwards();
-          })
-          .catch(() => {
-            Flash(
-              __('Something went wrong while adding your award. Please try again.'),
-              'alert',
-              noteData.flashContainer,
-            );
-          });
-      }
-      if (commandsChanges.spend_time != null || commandsChanges.time_estimate != null) {
-        sidebarTimeTrackingEventHub.$emit('timeTrackingUpdated', res);
-      }
+    throw new Error(__('Failed to save comment!'));
+  };
+  const processEmojiAward = res => {
+    const { commands_changes: commandsChanges } = res;
+    const { emoji_award: emojiAward } = commandsChanges || {};
+    if (!emojiAward) {
+      return res;
     }
-    if (errors && errors.commands_only) {
-      Flash(errors.commands_only, 'notice', noteData.flashContainer);
+    const votesBlock = $('.js-awards-block').eq(0);
+
+    return loadAwardsHandler()
+      .then(awardsHandler => {
+        awardsHandler.addAwardToEmojiBar(votesBlock, emojiAward);
+        awardsHandler.scrollToAwards();
+      })
+      .catch(() => {
+        Flash(
+          __('Something went wrong while adding your award. Please try again.'),
+          'alert',
+          noteData.flashContainer,
+        );
+      })
+      .then(() => res);
+  };
+
+  const processTimeTracking = res => {
+    const { commands_changes: commandsChanges } = res;
+    const { spend_time: spendTime, time_estimate: timeEstimate } = commandsChanges || {};
+    if (spendTime != null || timeEstimate != null) {
+      sidebarTimeTrackingEventHub.$emit('timeTrackingUpdated', {
+        commands_changes: commandsChanges,
+      });
     }
+
+    return res;
+  };
+
+  const removePlaceholder = res => {
     if (replyId) {
       commit(types.REMOVE_PLACEHOLDER_NOTES);
     }
     return res;
-  });
+  };
+
+  return dispatch(methodToDispatch, postData, { root: true })
+    .then(processErrors)
+    .then(processEmojiAward)
+    .then(processTimeTracking)
+    .then(removePlaceholder);
 };
 const pollSuccessCallBack = (resp, commit, state, getters, dispatch) => {
@@ -430,10 +452,13 @@ export const updateResolvableDiscussionsCounts = ({ commit }) =>
 export const submitSuggestion = (
   { commit, dispatch },
   { discussionId, noteId, suggestionId, flashContainer },
-) =>
-  Api.applySuggestion(suggestionId)
+) => {
+  const dispatchResolveDiscussion = () =>
+    dispatch('resolveDiscussion', { discussionId }).catch(() => {});
+
+  return Api.applySuggestion(suggestionId)
     .then(() => commit(types.APPLY_SUGGESTION, { discussionId, noteId, suggestionId }))
-    .then(() => dispatch('resolveDiscussion', { discussionId }).catch(() => {}))
+    .then(dispatchResolveDiscussion)
     .catch(err => {
       const defaultMessage = __(
         'Something went wrong while applying the suggestion. Please try again.',
@@ -442,6 +467,7 @@ export const submitSuggestion = (
       Flash(__(flashMessage), 'alert', flashContainer);
     });
+};
 export const convertToDiscussion = ({ commit }, noteId) =>
   commit(types.CONVERT_TO_DISCUSSION, noteId);

app/assets/javascripts/sidebar/components/confidential/confidential_issue_sidebar.vue

@@ -66,6 +66,7 @@ export default {
 <template>
   <div class="block issuable-sidebar-item confidentiality">
     <div
+      ref="collapseIcon"
       v-tooltip
       :title="tooltipLabel"
       class="sidebar-collapsed-icon"
@@ -80,6 +81,7 @@ export default {
       {{ __('Confidentiality') }}
       <a
         v-if="isEditable"
+        ref="editLink"
         class="float-right confidential-edit"
         href="#"
         data-track-event="click_edit_button"

doc/development/adding_database_indexes.md

@@ -108,7 +108,7 @@ This query outputs a list containing all indexes that are never used and sorts
 them by indexes sizes in descending order.  This query can be useful to
 determine if any previously indexes are useful after all. More information on
 the meaning of the various columns can be found at
-<https://www.postgresql.org/docs/current/static/monitoring-stats.html>.
+<https://www.postgresql.org/docs/current/monitoring-stats.html>.
 Because the output of this query relies on the actual usage of your database it
 may be affected by factors such as (but not limited to):

doc/development/architecture.md

@@ -157,7 +157,7 @@ Component statuses are linked to configuration documentation for each component.
 | [Elasticsearch](#elasticsearch) | Improved search within GitLab | [⤓][elasticsearch-omnibus] | [⤓][elasticsearch-charts] | [⤓][elasticsearch-charts] | [❌](https://gitlab.com/groups/gitlab-org/-/epics/153) | [⤓][elasticsearch-source] | [⤓][elasticsearch-gdk] | EE Only |
 | [Sentry integration](#sentry) | Error tracking for deployed apps | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | [⤓][sentry-integration] | CE & EE |
 | [Jaeger integration](#jaeger) | Distributed tracing for deployed apps | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | [⤓][jaeger-integration] | EE Only |
-| [GitLab Managed Apps](#gitlab-managed-apps) | Deploy [Helm](https://docs.helm.sh/), [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), [Cert-Manager](https://docs.cert-manager.io/en/latest/), [Prometheus](https://prometheus.io/docs/introduction/overview/), a [Runner](https://docs.gitlab.com/runner/), [JupyterHub](http://jupyter.org/), [Knative](https://cloud.google.com/knative) to a cluster | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | CE & EE |
+| [GitLab Managed Apps](#gitlab-managed-apps) | Deploy [Helm](https://helm.sh/docs/), [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/), [Cert-Manager](https://docs.cert-manager.io/en/latest/), [Prometheus](https://prometheus.io/docs/introduction/overview/), a [Runner](https://docs.gitlab.com/runner/), [JupyterHub](https://jupyter.org), [Knative](https://cloud.google.com/knative/) to a cluster | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | [⤓][managed-k8s-apps] | CE & EE |
 ### Component details

doc/development/code_review.md

@@ -18,7 +18,7 @@ recommended to pick someone who knows the domain well. You can read more about t
 importance of involving reviewer(s) in the section on the responsibility of the author below.
 If you need some guidance (e.g. it's your first merge request), feel free to ask
-one of the [Merge request coaches][team].
+one of the [Merge request coaches](https://about.gitlab.com/company/team/).
 If you need assistance with security scans or comments, feel free to include the
 Security Team (`@gitlab-com/gl-security`) in the review.
@@ -66,13 +66,13 @@ from teams other than your own.
 1. If your merge request includes frontend changes [^1], it must be
    **approved by a [frontend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab-ce_maintainers_frontend)**.
 1. If your merge request includes UX changes [^1], it must be
-   **approved by a [UX team member][team]**.
+   **approved by a [UX team member](https://about.gitlab.com/company/team/)**.
 1. If your merge request includes adding a new JavaScript library [^1], it must be
-   **approved by a [frontend lead][team]**.
+   **approved by a [frontend lead](https://about.gitlab.com/company/team/)**.
 1. If your merge request includes adding a new UI/UX paradigm [^1], it must be
-   **approved by a [UX lead][team]**.
+   **approved by a [UX lead](https://about.gitlab.com/company/team/)**.
 1. If your merge request includes a new dependency or a filesystem change, it must be
-   **approved by a [Distribution team member][team]**. See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/development/enablement/distribution/#how-to-work-with-distribution) for more details.
+   **approved by a [Distribution team member](https://about.gitlab.com/company/team/)**. See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/development/enablement/distribution/#how-to-work-with-distribution) for more details.
 #### Security requirements
@@ -172,7 +172,7 @@ required approvers.
 Maintainers must check before merging if the merge request is introducing new
 vulnerabilities, by inspecting the list in the Merge Request [Security
 Widget](../user/project/merge_requests/index.md#security-reports-ultimate).
-When in doubt, a [Security Engineer][team] can be involved. The list of detected
+When in doubt, a [Security Engineer](https://about.gitlab.com/company/team/) can be involved. The list of detected
 vulnerabilities must be either empty or containing:
 - dismissed vulnerabilities in case of false positives
@@ -433,7 +433,6 @@ Largely based on the [thoughtbot code review guide].
 [Return to Development documentation](README.md)
 [projects]: https://about.gitlab.com/handbook/engineering/projects/
-[team]: https://about.gitlab.com/team/
 [build handbook]: https://about.gitlab.com/handbook/build/handbook/build#how-to-work-with-build
 [^1]: Please note that specs other than JavaScript specs are considered backend code.
 [^2]: We encourage you to seek guidance from a database maintainer if your merge request is potentially introducing expensive queries. It is most efficient to comment on the line of code in question with the SQL queries so they can give their advice.

doc/development/contributing/design.md

@@ -5,7 +5,7 @@ For guidance on UX implementation at GitLab, please refer to our [Design System]
 The UX team uses labels to manage their workflow.
 The  ~"UX" label on an issue is a signal to the UX team that it will need UX attention.
-To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux) of the handbook.
+To better understand the priority by which UX tackles issues, see the [UX section](https://about.gitlab.com/handbook/engineering/ux/) of the handbook.
 Once an issue has been worked on and is ready for development, a UXer removes the ~"UX" label and applies the ~"UX ready" label to that issue.

doc/development/contributing/index.md

@@ -15,7 +15,7 @@ abbreviation.
 To get an overview of GitLab community membership including those that would be reviewing or merging your contributions, please visit [the community roles page](community_roles.md).
-If you want to know how the GitLab [core team]
+If you want to know how the GitLab [core team](https://about.gitlab.com/community/core-team/)
 operates please see [the GitLab contributing process](https://gitlab.com/gitlab-org/gitlab/blob/master/PROCESS.md).
 [GitLab Inc engineers should refer to the engineering workflow document](https://about.gitlab.com/handbook/engineering/workflow/)
@@ -24,7 +24,7 @@ operates please see [the GitLab contributing process](https://gitlab.com/gitlab-
 Please report suspected security vulnerabilities in private to
 `support@gitlab.com`, also see the
-[disclosure section on the GitLab.com website](https://about.gitlab.com/disclosure/).
+[disclosure section on the GitLab.com website](https://about.gitlab.com/security/disclosure/).
 Please do **NOT** create publicly viewable issues for suspected security
 vulnerabilities.
@@ -48,7 +48,7 @@ for audiences of all ages.
 If a contributor is no longer actively working on a submitted merge request
 we can decide that the merge request will be finished by one of our
-[Merge request coaches][team] or close the merge request. We make this decision
+[Merge request coaches](https://about.gitlab.com/company/team/) or close the merge request. We make this decision
 based on how important the change is for our product vision. If a merge request
 coach is going to finish the merge request we assign the
 ~"coach will finish" label. When a team member picks up a community contribution,
@@ -59,10 +59,10 @@ within the MR.
 ## Helping others
 Please help other GitLab users when you can.
-The methods people will use to seek help can be found on the [getting help page][getting-help].
+The methods people will use to seek help can be found on the [getting help page](https://about.gitlab.com/get-help/).
 Sign up for the mailing list, answer GitLab questions on StackOverflow or
-respond in the IRC channel. You can also sign up on [CodeTriage][codetriage] to help with
+respond in the IRC channel. You can also sign up on [CodeTriage](https://www.codetriage.com/gitlabhq/gitlabhq) to help with
 the remaining issues on the GitHub issue tracker.
 ## I want to contribute
@@ -70,7 +70,7 @@ the remaining issues on the GitHub issue tracker.
 If you want to contribute to GitLab,
 [issues with the `Accepting merge requests` label](issue_workflow.md#label-for-community-contributors)
 are a great place to start.
-If you have any questions or need help visit [Getting Help](https://about.gitlab.com/getting-help/#discussion) to
+If you have any questions or need help visit [Getting Help](https://about.gitlab.com/get-help/) to
 learn how to communicate with GitLab. If you're looking for a Gitter or Slack channel
 please consider we favor
 [asynchronous communication](https://about.gitlab.com/handbook/communication/#internal-communication) over real time communication. Thanks for your contribution!
@@ -85,7 +85,7 @@ When maintainers are reading through a merge request they may request guidance f
 Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance.  The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future.
-GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request.  For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches.
+GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/company/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request.  For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches.
 GitLab receives a lot of community contributions, so if your code has not been reviewed within two days (excluding weekend and public holidays) of its initial submission feel free to re-mention the appropriate merge request coach.
@@ -122,8 +122,3 @@ This [documentation](style_guides.md) outlines the current style guidelines.
 ---
 [Return to Development documentation](../README.md)
-
-[core team]: https://about.gitlab.com/core-team/
-[team]: https://about.gitlab.com/company/team/
-[getting-help]: https://about.gitlab.com/getting-help/
-[codetriage]: http://www.codetriage.com/gitlabhq/gitlabhq

doc/development/contributing/issue_workflow.md

@@ -22,7 +22,7 @@ once every quarter.
 The most important thing is making sure valid issues receive feedback from the
 development team. Therefore the priority is mentioning developers that can help
 on those issues. Please select someone with relevant experience from the
-[GitLab team](https://about.gitlab.com/team/).
+[GitLab team](https://about.gitlab.com/company/team/).
 If there is nobody mentioned with that expertise look in the commit history for
 the affected files to find someone.
@@ -152,7 +152,7 @@ As a team needs some way to collect the work their members are planning to be as
 Normally there is a 1:1 relationship between Stage labels and Group labels. In the spirit of "Everyone can contribute",
 any issue can be picked up by any group, depending on current priorities. For example, an issue labeled ~"devops::create" may be picked up by the ~"group::access" group.
-We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput).
+We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/).
 Please read [Stage and Group labels in Throughtput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context.
 ### Category labels
@@ -336,7 +336,7 @@ know how difficult the issue is. Additionally:
 - We advertise [`Accepting merge requests` issues with weight < 5](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None&sort=weight)
   as suitable for people that have never contributed to GitLab before on the
-  [Up For Grabs campaign](http://up-for-grabs.net)
+  [Up For Grabs campaign](https://up-for-grabs.net/#/)
 - We encourage people that have never contributed to any open source project to
   look for [`Accepting merge requests` issues with a weight of 1](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&assignee_id=None&sort=weight&weight=1)

doc/development/contributing/merge_request_workflow.md

@@ -89,7 +89,7 @@ request is as follows:
 1. Write tests for more complex migrations.
 1. Merge requests **must** adhere to the [merge request performance guidelines](../merge_request_performance_guidelines.md).
 1. For tests that use Capybara, read
-   [how to write reliable, asynchronous integration tests](https://robots.thoughtbot.com/write-reliable-asynchronous-integration-tests-with-capybara).
+   [how to write reliable, asynchronous integration tests](https://thoughtbot.com/blog/write-reliable-asynchronous-integration-tests-with-capybara).
 1. If your merge request introduces changes that require additional steps when
    installing GitLab from source, add them to `doc/install/installation.md` in
    the same merge request.
@@ -101,7 +101,7 @@ request is as follows:
 If you would like quick feedback on your merge request feel free to mention someone
 from the [core team](https://about.gitlab.com/community/core-team/) or one of the
-[merge request coaches](https://about.gitlab.com/team/). When having your code reviewed
+[merge request coaches](https://about.gitlab.com/company/team/). When having your code reviewed
 and when reviewing merge requests, please keep the [code review guidelines](../code_review.md)
 in mind. And if your code also makes changes to the database, or does expensive queries,
 check the [database review guidelines](../database_review.md).

doc/development/documentation/styleguide.md

@@ -1107,7 +1107,7 @@ Rendered example:
 ### cURL Examples
-Below is a set of [cURL][] examples that you can use in the API documentation.
+Below is a set of [cURL](https://curl.haxx.se) examples that you can use in the API documentation.
 #### Simple cURL command
@@ -1179,7 +1179,6 @@ restrict the sign-up e-mail domains of a GitLab instance to `*.example.com` and
 curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" --data "domain_whitelist[]=*.example.com" --data "domain_whitelist[]=example.net" https://gitlab.example.com/api/v4/application/settings
 ```
-[cURL]: http://curl.haxx.se/ "cURL website"
 [single spaces]: http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html
 [gfm]: ../../user/markdown.md#newlines "GitLab flavored markdown documentation"
 [ce-1242]: https://gitlab.com/gitlab-org/gitlab-foss/issues/1242

doc/development/elasticsearch.md

@@ -59,7 +59,7 @@ Additionally, if you need large repos or multiple forks for testing, please cons
 ## How does it work?
-The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/cc723071ad337573e0360a879cbf99bc4fb7adb9/ee/app/models/concerns/elastic/application_versioned_search.rb).
+The Elasticsearch integration depends on an external indexer. We ship an [indexer written in Go](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer). The user must trigger the initial indexing via a rake task but, after this is done, GitLab itself will trigger reindexing when required via `after_` callbacks on create, update, and destroy that are inherited from [/ee/app/models/concerns/elastic/application_versioned_search.rb](https://gitlab.com/gitlab-org/gitlab/blob/master/ee/app/models/concerns/elastic/application_versioned_search.rb).
 All indexing after the initial one is done via `ElasticIndexerWorker` (sidekiq jobs).
@@ -243,4 +243,4 @@ cluster.routing.allocation.disk.watermark.high: 10gb
 Restart Elasticsearch, and the `read_only_allow_delete` will clear on it's own.
-_from "Disk-based Shard Allocation | Elasticsearch Reference" [5.6](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/disk-allocator.html#disk-allocator) and [6.x](https://www.elastic.co/guide/en/elasticsearch/reference/6.x/disk-allocator.html)_
+_from "Disk-based Shard Allocation | Elasticsearch Reference" [5.6](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/disk-allocator.html#disk-allocator) and [6.x](https://www.elastic.co/guide/en/elasticsearch/reference/6.7/disk-allocator.html)_

doc/development/emails.md

@@ -17,10 +17,9 @@ dummy data.
 The previews live in [`app/mailers/previews`][previews] and can be viewed at
 [`/rails/mailers`](http://localhost:3000/rails/mailers).
-See the [Rails guides] for more info.
+See the [Rails guides](https://guides.rubyonrails.org/action_mailer_basics.html#previewing-emails) for more info.
 [previews]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/mailers/previews
-[Rails guides]: http://guides.rubyonrails.org/action_mailer_basics.html#previewing-emails
 ## Incoming email

doc/development/fe_guide/index.md

@@ -5,8 +5,8 @@ across GitLab's frontend team.
 ## Overview
-GitLab is built on top of [Ruby on Rails][rails] using [Haml][haml] and also a JavaScript based Frontend with [Vue.js][vue].
-Be wary of [the limitations that come with using Hamlit][hamlit-limits]. We also use [SCSS][scss] and plain JavaScript with
+GitLab is built on top of [Ruby on Rails](https://rubyonrails.org) using [Haml][haml] and also a JavaScript based Frontend with [Vue.js](https://vuejs.org).
+Be wary of [the limitations that come with using Hamlit][hamlit-limits]. We also use [SCSS](https://sass-lang.com) and plain JavaScript with
 modern ECMAScript standards supported through [Babel][babel] and ES module support through [webpack][webpack].
 Working with our frontend assets requires Node (v8.10.0 or greater) and Yarn
@@ -83,7 +83,7 @@ changes.
 ### [SCSS Style Guide](style_guide_scss.md)
-Our SCSS conventions which are enforced through [scss-lint][scss-lint].
+Our SCSS conventions which are enforced through [scss-lint](https://github.com/sds/scss-lint).
 ## [Performance](performance.md)
@@ -102,17 +102,13 @@ Our accessibility standards and resources.
 Frontend internationalization support is described in [this document](../i18n/).
 The [externalization part of the guide](../i18n/externalization.md) explains the helpers/methods available.
-[rails]: http://rubyonrails.org/
 [haml]: http://haml.info/
 [hamlit]: https://github.com/k0kubun/hamlit
 [hamlit-limits]: https://github.com/k0kubun/hamlit/blob/master/REFERENCE.md#limitations
-[scss]: http://sass-lang.com/
 [babel]: https://babeljs.io/
 [webpack]: https://webpack.js.org/
 [jquery]: https://jquery.com/
-[vue]: http://vuejs.org/
 [axios]: https://github.com/axios/axios
 [airbnb-js-style-guide]: https://github.com/airbnb/javascript
-[scss-lint]: https://github.com/brigade/scss-lint
 [install]: ../../install/installation.md#4-node
 [requirements]: ../../install/requirements.md#supported-web-browsers

doc/development/fe_guide/performance.md

@@ -165,14 +165,12 @@ General tips:
 ## Additional Resources
-- [WebPage Test][web-page-test] for testing site loading time and size.
+- [WebPage Test](https://www.webpagetest.org) for testing site loading time and size.
 - [Google PageSpeed Insights][pagespeed-insights] grades web pages and provides feedback to improve the page.
-- [Profiling with Chrome DevTools][google-devtools-profiling]
+- [Profiling with Chrome DevTools](https://developers.google.com/web/tools/chrome-devtools/)
 - [Browser Diet][browser-diet] is a community-built guide that catalogues practical tips for improving web page performance.
-[web-page-test]: http://www.webpagetest.org/
 [pagespeed-insights]: https://developers.google.com/speed/pagespeed/insights/
-[google-devtools-profiling]: https://developers.google.com/web/tools/chrome-devtools/profile/?hl=en
 [browser-diet]: https://browserdiet.com/
 [high-perf-animations]: https://www.html5rocks.com/en/tutorials/speed/high-performance-animations/
 [flip]: https://aerotwist.com/blog/flip-your-animations/

doc/development/fe_guide/style_guide_scss.md

@@ -27,8 +27,8 @@ New utility classes should be added to [`utilities.scss`](https://gitlab.com/git
 | Font size | `.text-{size}` | `.text-2` |
 - `{variant}` is one of 'primary', 'secondary', 'success', 'warning', 'error'
-- `{shade}` is on of the shades listed on [colors](https://design.gitlab.com/foundations/colors/)
-- `{size}` is a number from 1-6 from our [Type scale](https://design.gitlab.com/foundations/typography)
+- `{shade}` is on of the shades listed on [colors](https://design.gitlab.com/product-foundations/colors/)
+- `{size}` is a number from 1-6 from our [Type scale](https://design.gitlab.com/product-foundations/typography)
 #### When should I create component classes?
@@ -46,8 +46,8 @@ Examples of component classes that were created using "utility-first" include:
 Inspiration:
-- <https://tailwindcss.com/docs/utility-first>
-- <https://tailwindcss.com/docs/extracting-components>
+- <https://tailwindcss.com/docs/utility-first/>
+- <https://tailwindcss.com/docs/extracting-components/>
 ### Naming
@@ -236,7 +236,7 @@ Before adding a new variable for a color or a size, guarantee:
 ## Linting
-We use [SCSS Lint][scss-lint] to check for style guide conformity. It uses the
+We use [SCSS Lint](https://github.com/sds/scss-lint) to check for style guide conformity. It uses the
 ruleset in `.scss-lint.yml`, which is located in the home directory of the
 project.
@@ -245,7 +245,7 @@ scss_lint` in the GitLab directory. SCSS Lint will also run in GitLab CI to
 catch any warnings.
 If the Rake task is throwing warnings you don't understand, SCSS Lint's
-documentation includes [a full list of their linters][scss-lint-documentation].
+documentation includes [a full list of their linters][scss-lint-documentation](https://github.com/sds/scss-lint/blob/master/lib/scss_lint/linter/README.md).
 ### Fixing issues
@@ -260,7 +260,7 @@ Note that this won't fix every problem, but it should fix a majority.
 ### Ignoring issues
 If you want a line or set of lines to be ignored by the linter, you can use
-`// scss-lint:disable RuleName` ([more info][disabling-linters]):
+`// scss-lint:disable RuleName` ([more info](https://github.com/sds/scss-lint#disabling-linters-via-source)):
 ```scss
 // This lint rule is disabled because it is supported only in Chrome/Safari
@@ -279,6 +279,3 @@ guide is ignored in this instance.
 [csscomb]: https://github.com/csscomb/csscomb.js
 [node]: https://github.com/nodejs/node
 [npm]: https://www.npmjs.com/
-[scss-lint]: https://github.com/brigade/scss-lint
-[scss-lint-documentation]: https://github.com/brigade/scss-lint/blob/master/lib/scss_lint/linter/README.md
-[disabling-linters]: https://github.com/brigade/scss-lint#disabling-linters-via-source

doc/development/fe_guide/vue.md

 # Vue
-To get started with Vue, read through [their documentation][vue-docs].
+To get started with Vue, read through [their documentation](https://vuejs.org/v2/guide/).
 ## Examples
@@ -290,7 +290,6 @@ One should apply to be a Vue.js expert by opening an MR when the Merge Request's
 - Vuex code follows the [documented pattern](vuex.md#actions-pattern-request-and-receive-namespaces)
 - Knowledge about the existing Vue and Vuex applications and existing reusable components
-[vue-docs]: http://vuejs.org/guide/index.html
 [issue-boards]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/boards
 [environments-table]: https://gitlab.com/gitlab-org/gitlab-foss/tree/master/app/assets/javascripts/environments
 [page_specific_javascript]: ./performance.md#page-specific-javascript
@@ -298,5 +297,5 @@ One should apply to be a Vue.js expert by opening an MR when the Merge Request's
 [state-management]: https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch
 [one-way-data-flow]: https://vuejs.org/v2/guide/components.html#One-Way-Data-Flow
 [vue-test]: https://vuejs.org/v2/guide/unit-testing.html
-[flux]: https://facebook.github.io/flux
+[flux]: https://facebook.github.io/flux/
 [axios]: https://github.com/axios/axios

doc/development/fe_guide/vuex.md

@@ -232,7 +232,7 @@ import { mapGetters } from 'vuex';
 ### `mutation_types.js`
-From [vuex mutations docs][vuex-mutations]:
+From [vuex mutations docs](https://vuex.vuejs.org/guide/mutations.html):
 > 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
@@ -336,7 +336,7 @@ export default {
 #### Testing Vuex concerns
-Refer to [vuex docs][vuex-testing] regarding testing Actions, Getters and Mutations.
+Refer to [vuex docs](https://vuex.vuejs.org/guide/testing.html) regarding testing Actions, Getters and Mutations.
 #### Testing components that need a store
@@ -396,6 +396,3 @@ export default () => {};
 ```
 [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

doc/development/gotchas.md

@@ -144,13 +144,11 @@ refresh_service.execute(oldrev, newrev, ref)
 ## Do not `rescue Exception`
-See ["Why is it bad style to `rescue Exception => e` in Ruby?"][Exception].
+See ["Why is it bad style to `rescue Exception => e` in Ruby?"](https://stackoverflow.com/questions/10048173/why-is-it-bad-style-to-rescue-exception-e-in-ruby).
 _**Note:** This rule is [enforced automatically by
 Rubocop](https://gitlab.com/gitlab-org/gitlab/blob/8-4-stable/.rubocop.yml#L911-914)._
-[Exception]: http://stackoverflow.com/q/10048173/223897
-
 ## Do not use inline JavaScript in views
 Using the inline `:javascript` Haml filters comes with a
@@ -161,4 +159,4 @@ in an initializer._
 ### Further reading
-- Stack Overflow: [Why you should not write inline JavaScript](http://programmers.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting)
+- Stack Overflow: [Why you should not write inline JavaScript](https://softwareengineering.stackexchange.com/questions/86589/why-should-i-avoid-inline-scripting)

doc/development/i18n/externalization.md

@@ -323,7 +323,7 @@ bin/rake gettext:regenerate
 This command will update `locale/gitlab.pot` file with the newly externalized
 strings and remove any strings that aren't used anymore. You should check this
 file in. Once the changes are on master, they will be picked up by
-[Crowdin](http://translate.gitlab.com) and be presented for
+[Crowdin](https://translate.gitlab.com) and be presented for
 translation.
 We don't need to check in any changes to the