From 6ed0ec2a4be2f47f9c016c256e22280ba811ae53 Mon Sep 17 00:00:00 2001
From: Shivraj Koli <kolishivraj05@gmail.com>
Date: Thu, 4 Aug 2022 14:57:56 +0000
Subject: [PATCH] Use a link instead of a raw URL

This URL is long and not pretty. Link instead.
---
 doc/development/fe_guide/style/vue.md            | 16 ++++++++--------
 doc/development/fe_guide/vue.md                  | 10 +++++-----
 doc/development/shell_commands.md                |  2 +-
 .../dashboards/stage_group_dashboard.md          |  2 +-
 .../testing_guide/frontend_testing.md            |  2 +-
 doc/development/testing_guide/review_apps.md     |  2 +-
 doc/development/testing_guide/testing_levels.md  |  4 ++--
 doc/development/workhorse/configuration.md       |  6 +++---
 doc/development/workhorse/gitlab_features.md     |  2 +-
 doc/development/workhorse/index.md               |  4 ++--
 doc/install/installation.md                      |  2 +-
 11 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/doc/development/fe_guide/style/vue.md b/doc/development/fe_guide/style/vue.md
index 5c79d47e7b044..ae9330c3e3eff 100644
--- a/doc/development/fe_guide/style/vue.md
+++ b/doc/development/fe_guide/style/vue.md
@@ -448,9 +448,9 @@ Typically, when testing a Vue component, the component should be "re-mounted" in
 To achieve this:
 
 1. Create a mutable `wrapper` variable inside the top-level `describe` block.
-1. Mount the component using [`mount`](https://vue-test-utils.vuejs.org/api/#mount)/
-[`shallowMount`](https://vue-test-utils.vuejs.org/api/#shallowMount).
-1. Reassign the resulting [`Wrapper`](https://vue-test-utils.vuejs.org/api/wrapper/#wrapper)
+1. Mount the component using [`mount`](https://v1.test-utils.vuejs.org/api/#mount)/
+[`shallowMount`](https://v1.test-utils.vuejs.org/api/#shallowMount).
+1. Reassign the resulting [`Wrapper`](https://v1.test-utils.vuejs.org/api/wrapper/#wrapper)
 instance to our `wrapper` variable.
 
 Creating a global, mutable wrapper provides a number of advantages, including the ability to:
@@ -476,8 +476,8 @@ Creating a global, mutable wrapper provides a number of advantages, including th
 
 To avoid duplicating our mounting logic, it's useful to define a `createComponent` factory function
 that we can reuse in each test block. This is a closure which should reassign our `wrapper` variable
-to the result of [`mount`](https://vue-test-utils.vuejs.org/api/#mount) and
-[`shallowMount`](https://vue-test-utils.vuejs.org/api/#shallowMount):
+to the result of [`mount`](https://v1.test-utils.vuejs.org/api/#mount) and
+[`shallowMount`](https://v1.test-utils.vuejs.org/api/#shallowMount):
 
 ```javascript
 import MyComponent from '~/path/to/my_component.vue';
@@ -579,9 +579,9 @@ the mounting function (`mount` or `shallowMount`) to be used to mount the compon
 
 ### Setting component state
 
-1. Avoid using [`setProps`](https://vue-test-utils.vuejs.org/api/wrapper/#setprops) to set
+1. Avoid using [`setProps`](https://v1.test-utils.vuejs.org/api/wrapper/#setprops) to set
 component state wherever possible. Instead, set the component's
-[`propsData`](https://vue-test-utils.vuejs.org/api/options.html#propsdata) when mounting the component:
+[`propsData`](https://v1.test-utils.vuejs.org/api/options.html#propsdata) when mounting the component:
 
     ```javascript
     // bad
@@ -659,7 +659,7 @@ The goal of this accord is to make sure we are all on the same page.
    1. If an outside jQuery Event needs to be listen to inside the Vue application, you may use
    jQuery event listeners.
    1. We avoid adding new jQuery events when they are not required. Instead of adding new jQuery
-   events take a look at [different methods to do the same task](https://vuejs.org/v2/api/#vm-emit).
+   events take a look at [different methods to do the same task](https://v2.vuejs.org/v2/api/#vm-emit).
 1. You may query the `window` object one time, while bootstrapping your application for application
 specific data (for example, `scrollTo` is ok to access anytime). Do this access during the
 bootstrapping of your application.
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 7943ae119be4d..27660c0f5f7d9 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -71,7 +71,7 @@ component, is that you avoid creating a fixture or an HTML element in the unit t
 
 ##### `provide` and `inject`
 
-Vue supports dependency injection through [`provide` and `inject`](https://vuejs.org/v2/api/#provide-inject).
+Vue supports dependency injection through [`provide` and `inject`](https://v2.vuejs.org/v2/api/#provide-inject).
 In the component the `inject` configuration accesses the values `provide` passes down.
 This example of a Vue app initialization shows how the `provide` configuration passes a value from HAML to the component:
 
@@ -266,7 +266,7 @@ return new Vue({
 
 #### Accessing feature flags
 
-Use the [`provide` and `inject`](https://vuejs.org/v2/api/#provide-inject) mechanisms
+Use the [`provide` and `inject`](https://v2.vuejs.org/v2/api/#provide-inject) mechanisms
 in Vue to make feature flags available to any descendant components in a Vue
 application. The `glFeatures` object is already provided in `commons/vue.js`, so
 only the mixin is required to use the flags:
@@ -339,7 +339,7 @@ Check this [page](vuex.md) for more details.
 
 ### Mixing Vue and JavaScript classes (in the data function)
 
-In the [Vue documentation](https://vuejs.org/v2/api/#Options-Data) the Data function/object is defined as follows:
+In the [Vue documentation](https://v2.vuejs.org/v2/api/#Options-Data) the Data function/object is defined as follows:
 
 > The data object for the Vue instance. Vue recursively converts its properties into getter/setters
 to make it "reactive". The object must be plain: native objects such as browser API objects and
@@ -348,7 +348,7 @@ recommended to observe objects with their own stateful behavior.
 
 Based on the Vue guidance:
 
-- **Do not** use or create a JavaScript class in your [data function](https://vuejs.org/v2/api/#data),
+- **Do not** use or create a JavaScript class in your [data function](https://v2.vuejs.org/v2/api/#data),
 such as `user: new User()`.
 - **Do not** add new JavaScript class implementations.
 - **Do** use [GraphQL](../api_graphql_styleguide.md), [Vuex](vuex.md) or a set of components if
@@ -531,7 +531,7 @@ Each Vue component has a unique output. This output is always present in the ren
 Although each method of a Vue component can be tested individually, our goal is to test the output
 of the render function, which represents the state at all times.
 
-Visit the [Vue testing guide](https://vuejs.org/v2/guide/testing.html#Unit-Testing) for help
+Visit the [Vue testing guide](https://v2.vuejs.org/v2/guide/testing.html#Unit-Testing) for help
 testing the rendered output.
 
 Here's an example of a well structured unit test for [this Vue component](#appendix---vue-component-subject-under-test):
diff --git a/doc/development/shell_commands.md b/doc/development/shell_commands.md
index fcb8c20bdd374..d8a3f86685e1a 100644
--- a/doc/development/shell_commands.md
+++ b/doc/development/shell_commands.md
@@ -17,7 +17,7 @@ These guidelines are meant to make your code more reliable _and_ secure.
 
 ## Use File and FileUtils instead of shell commands
 
-Sometimes we invoke basic Unix commands via the shell when there is also a Ruby API for doing it. Use the Ruby API if it exists. <https://www.ruby-doc.org/stdlib-2.0.0/libdoc/fileutils/rdoc/FileUtils.html#module-FileUtils-label-Module+Functions>
+Sometimes we invoke basic Unix commands via the shell when there is also a Ruby API for doing it. Use [the Ruby API](https://ruby-doc.org/stdlib-2.0.0/libdoc/fileutils/rdoc/FileUtils.html#module-FileUtils-label-Module+Functions) if it exists.
 
 ```ruby
 # Wrong
diff --git a/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md b/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
index c1831cfce69ec..c8c18b93a8fdc 100644
--- a/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
+++ b/doc/development/stage_group_observability/dashboards/stage_group_dashboard.md
@@ -56,7 +56,7 @@ description, note the following:
 
 To inspect the raw data of the panel for further calculation, select **Inspect** from the dropdown
 list of a panel. Queries, raw data, and panel JSON structure are available.
-Read more at [Grafana panel inspection](https://grafana.com/docs/grafana/latest/panels/inspect-panel/).
+Read more at [Grafana panel inspection](http://grafana.com/docs/grafana/next/panels/query-a-data-source/).
 
 All the dashboards are powered by [Grafana](https://grafana.com/), a frontend for displaying metrics.
 Grafana consumes the data returned from queries to backend Prometheus data source, then presents it
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index d91c53823e217..9410c2f07a513 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -466,7 +466,7 @@ it('waits for an Ajax call', () => {
 
 #### Vue rendering
 
-Use [`nextTick()`](https://vuejs.org/v2/api/#Vue-nextTick) to wait until a Vue component is
+Use [`nextTick()`](https://v2.vuejs.org/v2/api/#Vue-nextTick) to wait until a Vue component is
 re-rendered.
 
 **in Jest:**
diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md
index 532bb9fcdefcd..b272d23522e1c 100644
--- a/doc/development/testing_guide/review_apps.md
+++ b/doc/development/testing_guide/review_apps.md
@@ -25,7 +25,7 @@ For any of the following scenarios, the `start-review-app-pipeline` job would be
 
 On every [pipeline](https://gitlab.com/gitlab-org/gitlab/pipelines/125315730) in the `qa` stage (which comes after the
 `review` stage), the `review-qa-smoke` and `review-qa-reliable` jobs are automatically started. The `review-qa-smoke` runs
-the QA smoke suite and the `review-qa-reliable` executes E2E tests identified as [reliable](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/reliable-tests).
+the QA smoke suite and the `review-qa-reliable` executes E2E tests identified as [reliable](https://about.gitlab.com/handbook/engineering/quality/quality-engineering/reliable-tests/).
 
 `review-qa-*` jobs ensure that end-to-end tests for the changes in the merge request pass in a live environment. This shifts the identification of e2e failures from an environment on the path to production to the merge request, to prevent breaking features on GitLab.com or costly GitLab.com deployment blockers. `review-qa-*` failures should be investigated with counterpart SET involvement if needed to help determine the root cause of the error.
 
diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md
index 02f32a031dcf7..c1bf3609b53a8 100644
--- a/doc/development/testing_guide/testing_levels.md
+++ b/doc/development/testing_guide/testing_levels.md
@@ -115,7 +115,7 @@ graph RL
   Testing the value of a constant means copying it, resulting in extra effort without additional confidence that the value is correct.
 - **Vue components**:
   Computed properties, methods, and lifecycle hooks can be considered an implementation detail of components, are implicitly covered by component tests, and don't need to be tested.
-  For more information, see the [official Vue guidelines](https://vue-test-utils.vuejs.org/guides/#getting-started).
+  For more information, see the [official Vue guidelines](https://v1.test-utils.vuejs.org/guides/#getting-started).
 
 #### What to mock in unit tests
 
@@ -208,7 +208,7 @@ graph RL
   Similar to unit tests, background operations cannot be stopped or waited on. This means they continue running in the following tests and cause side effects.
 - **Child components**:
   Every component is tested individually, so child components are mocked.
-  See also [`shallowMount()`](https://vue-test-utils.vuejs.org/api/#shallowmount)
+  See also [`shallowMount()`](https://v1.test-utils.vuejs.org/api/#shallowmount)
 
 #### What *not* to mock in component tests
 
diff --git a/doc/development/workhorse/configuration.md b/doc/development/workhorse/configuration.md
index b86bb824ea1eb..f71a0b345e090 100644
--- a/doc/development/workhorse/configuration.md
+++ b/doc/development/workhorse/configuration.md
@@ -211,7 +211,7 @@ Workhorse supports distributed tracing through [LabKit](https://gitlab.com/gitla
 using [OpenTracing APIs](https://opentracing.io).
 
 By default, no tracing implementation is linked into the binary. You can link in
-different OpenTracing providers with [build tags](https://golang.org/pkg/go/build/#hdr-Build_Constraints)
+different OpenTracing providers with [build tags](https://pkg.go.dev/go/build#hdr-Build_Constraints)
 or build constraints by setting the `BUILD_TAGS` make variable.
 
 For more details of the supported providers, refer to LabKit. For an example of
@@ -278,9 +278,9 @@ trusted_cidrs_for_x_forwarded_for = ["10.0.0.0/8", "127.0.0.1/32"]
 ## Continuous profiling
 
 Workhorse supports continuous profiling through [LabKit](https://gitlab.com/gitlab-org/labkit/)
-using [Stackdriver Profiler](https://cloud.google.com/profiler). By default, the
+using [Stackdriver Profiler](https://cloud.google.com/products/operations). By default, the
 Stackdriver Profiler implementation is linked in the binary using
-[build tags](https://golang.org/pkg/go/build/#hdr-Build_Constraints), though it's not
+[build tags](https://pkg.go.dev/go/build#hdr-Build_Constraints), though it's not
 required and can be skipped. For example:
 
 ```shell
diff --git a/doc/development/workhorse/gitlab_features.md b/doc/development/workhorse/gitlab_features.md
index 365cc7991d895..3b240d4cbc661 100644
--- a/doc/development/workhorse/gitlab_features.md
+++ b/doc/development/workhorse/gitlab_features.md
@@ -70,4 +70,4 @@ memory than it costs to have Workhorse look after it.
 - Workhorse does not clean up idle client connections.
 - We assume that all requests to Rails pass through Workhorse.
 
-For more information see ['A brief history of GitLab Workhorse'](https://about.gitlab.com/2016/04/12/a-brief-history-of-gitlab-workhorse/).
+For more information see ['A brief history of GitLab Workhorse'](https://about.gitlab.com/blog/2016/04/12/a-brief-history-of-gitlab-workhorse/).
diff --git a/doc/development/workhorse/index.md b/doc/development/workhorse/index.md
index 3aa7e945f5368..de3636fa11262 100644
--- a/doc/development/workhorse/index.md
+++ b/doc/development/workhorse/index.md
@@ -21,7 +21,7 @@ but that repository is no longer used for development.
 
 ## Install Workhorse
 
-To install GitLab Workhorse you need [Go 1.15 or newer](https://golang.org/dl) and
+To install GitLab Workhorse you need [Go 1.15 or newer](https://go.dev/dl) and
 [GNU Make](https://www.gnu.org/software/make/).
 
 To install into `/usr/local/bin` run `make install`.
@@ -44,7 +44,7 @@ On some operating systems, such as FreeBSD, you may have to use
 
 ### Run time dependencies
 
-Workhorse uses [ExifTool](https://www.sno.phy.queensu.ca/~phil/exiftool/) for
+Workhorse uses [ExifTool](https://exiftool.org/) for
 removing EXIF data (which may contain sensitive information) from uploaded
 images. If you installed GitLab:
 
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 2f2ae016eddfc..cb48ef5abc9a4 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -1064,7 +1064,7 @@ See the [OmniAuth integration documentation](../integration/omniauth.md).
 ### Build your projects
 
 GitLab can build your projects. To enable that feature, you need runners to do that for you.
-See the [GitLab Runner section](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/#gitlab-runner) to install it.
+See the [GitLab Runner section](https://docs.gitlab.com/runner/) to install it.
 
 ### Adding your Trusted Proxies
 
-- 
GitLab