Add latest changes from gitlab-org/gitlab@master

21 files changed, 71 insertions, 39 deletions

diff --git a/doc/development/database/batched_background_migrations.md b/doc/development/database/batched_background_migrations.md
index f3ea82b5c61..b273d9c9529 100644
--- a/doc/development/database/batched_background_migrations.md
+++ b/doc/development/database/batched_background_migrations.md
@@ -186,6 +186,40 @@ Bump to the [import/export version](../../user/project/settings/import_export.md
 be required, if importing a project from a prior version of GitLab requires the
 data to be in the new format.
 
+## Job arguments
+
+`BatchedMigrationJob` provides the `job_arguments` helper method for job classes to define the job arguments they need.
+
+Batched migrations scheduled with `queue_batched_background_migration` **must** use the helper to define the job arguments:
+
+```ruby
+queue_batched_background_migration(
+  'CopyColumnUsingBackgroundMigrationJob',
+  TABLE_NAME,
+  'name', 'name_convert_to_text',
+  job_interval: DELAY_INTERVAL
+)
+```
+
+In this example, `copy_from` returns `name`, and `copy_to` returns `name_convert_to_text`:
+
+```ruby
+class CopyColumnUsingBackgroundMigrationJob < BatchedMigrationJob
+  job_arguments :copy_from, :copy_to
+
+  def perform
+    from_column = connection.quote_column_name(copy_from)
+    to_column = connection.quote_column_name(copy_to)
+
+    assignment_clause = "#{to_column} = #{from_column}"
+
+    each_sub_batch(operation_name: :update_all) do |relation|
+      relation.update_all(assignment_clause)
+    end
+  end
+end
+```
+
 ## Example
 
 The `routes` table has a `source_type` field that's used for a polymorphic relationship.
@@ -221,8 +255,6 @@ background migration.
    correctly handled by the batched migration framework. Any subclass of
    `BatchedMigrationJob` is initialized with necessary arguments to
    execute the batch, as well as a connection to the tracking database.
-   Additional `job_arguments` set on the migration are passed to the
-   job's `perform` method.
 
 1. Add a new trigger to the database to update newly created and updated routes,
    similar to this example:
diff --git a/doc/development/documentation/site_architecture/index.md b/doc/development/documentation/site_architecture/index.md
index 1dadbaa7051..1e1ba45bd2a 100644
--- a/doc/development/documentation/site_architecture/index.md
+++ b/doc/development/documentation/site_architecture/index.md
@@ -257,7 +257,7 @@ If you don't specify `editor:`, the simple one is used by default.
 
 ## Algolia search engine
 
-The docs site uses [Algolia DocSearch](https://community.algolia.com/docsearch/)
+The docs site uses [Algolia DocSearch](https://docsearch.algolia.com/)
 for its search function.
 
 Learn more in <https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/doc/docsearch.md>.
diff --git a/doc/development/fe_guide/style/vue.md b/doc/development/fe_guide/style/vue.md
index 5c79d47e7b0..ae9330c3e3e 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 7943ae119be..27660c0f5f7 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/github_importer.md b/doc/development/github_importer.md
index 57cb74a6159..963350def80 100644
--- a/doc/development/github_importer.md
+++ b/doc/development/github_importer.md
@@ -72,7 +72,7 @@ This worker imports all pull requests. For every pull request a job for the
 ### 5. Stage::ImportPullRequestsMergedByWorker
 
 This worker imports the pull requests' _merged-by_ user information. The [_List pull
-requests_](https://docs.github.com/en/rest/reference/pulls#list-pull-requests)
+requests_](https://docs.github.com/en/rest/pulls#list-pull-requests)
 API doesn't provide this information. Therefore, this stage must fetch each merged pull request
 individually to import this information. A
 `Gitlab::GithubImport::ImportPullRequestMergedByWorker` job is scheduled for each fetched pull
diff --git a/doc/development/gitlab_flavored_markdown/specification_guide/index.md b/doc/development/gitlab_flavored_markdown/specification_guide/index.md
index c1f7dbf756b..756b87cd407 100644
--- a/doc/development/gitlab_flavored_markdown/specification_guide/index.md
+++ b/doc/development/gitlab_flavored_markdown/specification_guide/index.md
@@ -111,7 +111,7 @@ GFM and GLFM each have an official specification, which includes both:
 1. Generic extensions to the CommonMark standard.
 
 For example, GFM adds the
-[`strikethrough` extension](https://github.github.com/gfm/https://github.github.com/gfm/#strikethrough-extension-),
+[`strikethrough` extension](https://github.github.com/gfm/#strikethrough-extension-),
 and GLFM adds the
 [`color chips` extension](../../../user/markdown.md#colors).
 These extensions in the official specifications are not dependent upon any specific
diff --git a/doc/development/integrations/index.md b/doc/development/integrations/index.md
index 5d1bd5ad61c..0387ba2e4dd 100644
--- a/doc/development/integrations/index.md
+++ b/doc/development/integrations/index.md
@@ -273,7 +273,7 @@ When developing a new integration, we also recommend you gate the availability b
 
 You can provide help text in the integration form, including links to off-site documentation,
 as described above in [Customize the frontend form](#customize-the-frontend-form). Refer to
-our [usability guidelines](https://design.gitlab.com/usability/helping-users) for help text.
+our [usability guidelines](https://design.gitlab.com/usability/helping-users/) for help text.
 
 For more detailed documentation, provide a page in `doc/user/project/integrations`,
 and link it from the [Integrations overview](../../user/project/integrations/index.md).
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index 974ed9d6aeb..37ab71e2b34 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -500,7 +500,7 @@ We recommend that you use the identifiers the GitLab scanners already define:
 | [ELSA](https://linux.oracle.com/security/) | `elsa` | ELSA-2020-0085 |
 | [OSVD](https://cve.mitre.org/data/refs/refmap/source-OSVDB.html) | `osvdb` | OSVDB-113928 |
 | [OWASP](https://owasp.org/Top10/) | `owasp` | A01:2021–Broken Access Control Design |
-| [RHSA](https://access.redhat.com/errata/#/) | `rhsa` | RHSA-2020:0111 |
+| [RHSA](https://access.redhat.com/errata-search/#/) | `rhsa` | RHSA-2020:0111 |
 | [USN](https://ubuntu.com/security/notices) | `usn` | USN-4234-1 |
 | [WASC](http://projects.webappsec.org/Threat-Classification-Reference-Grid)  | `wasc` | WASC-19 |
 
diff --git a/doc/development/merge_request_concepts/index.md b/doc/development/merge_request_concepts/index.md
index 1320cd6f9f3..f8a367ac328 100644
--- a/doc/development/merge_request_concepts/index.md
+++ b/doc/development/merge_request_concepts/index.md
@@ -34,7 +34,7 @@ This area of the merge request is where all of the options and commit messages a
 
 Reports are widgets within the merge request that report information about changes within the merge request. These widgets provide information to better help the author understand the changes and further improvements to the proposed changes.
 
-[Design Documentation](https://design.gitlab.com/regions/merge-request-reports)
+[Design Documentation](https://design.gitlab.com/regions/merge-request-reports/)
 
 ![merge request reports](../img/merge_request_reports_v14_7.png)
 
diff --git a/doc/development/secure_coding_guidelines.md b/doc/development/secure_coding_guidelines.md
index 9048da77071..8053b4285e6 100644
--- a/doc/development/secure_coding_guidelines.md
+++ b/doc/development/secure_coding_guidelines.md
@@ -196,7 +196,7 @@ Go's [`regexp`](https://pkg.go.dev/regexp) package uses `re2` and isn't vulnerab
 
 - [Rubular](https://rubular.com/) is a nice online tool to fiddle with Ruby Regexps.
 - [Runaway Regular Expressions](https://www.regular-expressions.info/catastrophic.html)
-- [The impact of regular expression denial of service (ReDoS) in practice: an empirical study at the ecosystem scale](https://people.cs.vt.edu/~davisjam/downloads/publications/DavisCoghlanServantLee-EcosystemREDOS-ESECFSE18.pdf). This research paper discusses approaches to automatically detect ReDoS vulnerabilities.
+- [The impact of regular expression denial of service (ReDoS) in practice: an empirical study at the ecosystem scale](https://davisjam.github.io/files/publications/DavisCoghlanServantLee-EcosystemREDOS-ESECFSE18.pdf). This research paper discusses approaches to automatically detect ReDoS vulnerabilities.
 - [Freezing the web: A study of ReDoS vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.
 
 ## Server Side Request Forgery (SSRF)
diff --git a/doc/development/service_ping/implement.md b/doc/development/service_ping/implement.md
index 9a4f4e52241..bca47338c40 100644
--- a/doc/development/service_ping/implement.md
+++ b/doc/development/service_ping/implement.md
@@ -271,7 +271,7 @@ Arguments:
 
 Example of implementation:
 
-Using Redis methods [`INCR`](https://redis.io/commands/incr), [`GET`](https://redis.io/commands/get), and [`Gitlab::UsageDataCounters::WikiPageCounter`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/wiki_page_counter.rb)
+Using Redis methods [`INCR`](https://redis.io/commands/incr/), [`GET`](https://redis.io/commands/get/), and [`Gitlab::UsageDataCounters::WikiPageCounter`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/usage_data_counters/wiki_page_counter.rb)
 
 ##### `UsageData` API
 
@@ -316,7 +316,7 @@ Enabled by default in GitLab 13.7 and later.
 #### Redis HLL counters
 
 WARNING:
-HyperLogLog (HLL) is a probabilistic algorithm and its **results always includes some small error**. According to [Redis documentation](https://redis.io/commands/pfcount), data from
+HyperLogLog (HLL) is a probabilistic algorithm and its **results always includes some small error**. According to [Redis documentation](https://redis.io/commands/pfcount/), data from
 used HLL implementation is "approximated with a standard error of 0.81%".
 
 NOTE:
@@ -324,7 +324,7 @@ NOTE:
 
 With `Gitlab::UsageDataCounters::HLLRedisCounter` we have available data structures used to count unique values.
 
-Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd) and [PFCOUNT](https://redis.io/commands/pfcount).
+Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd/) and [PFCOUNT](https://redis.io/commands/pfcount/).
 
 ##### Add new events
 
diff --git a/doc/development/shell_commands.md b/doc/development/shell_commands.md
index fcb8c20bdd3..d8a3f86685e 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/snowplow/implementation.md b/doc/development/snowplow/implementation.md
index f8e37aee1e0..9a923b115a2 100644
--- a/doc/development/snowplow/implementation.md
+++ b/doc/development/snowplow/implementation.md
@@ -431,7 +431,7 @@ To test backend Snowplow events, use the `expect_snowplow_event` helper. For mor
 
 ### Performance
 
-We use the [AsyncEmitter](https://docs.snowplowanalytics.com/docs/collecting-data/collecting-from-own-applications/ruby-tracker/emitters/#the-asyncemitter-class) when tracking events, which allows for instrumentation calls to be run in a background thread. This is still an active area of development.
+We use the [AsyncEmitter](https://snowplow.github.io/snowplow-ruby-tracker/SnowplowTracker/AsyncEmitter.html) when tracking events, which allows for instrumentation calls to be run in a background thread. This is still an active area of development.
 
 ## Develop and test Snowplow
 
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 c1831cfce69..c8c18b93a8f 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/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 06359d612ad..b2d9ea85b05 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -235,7 +235,7 @@ Each type of scheduled pipeline generates a static link for the latest test repo
 - [`staging-sanity`](https://storage.googleapis.com/gitlab-qa-allure-reports/staging-sanity/master/index.html)
 - [`staging-sanity-no-admin`](https://storage.googleapis.com/gitlab-qa-allure-reports/staging-sanity-no-admin/master/index.html)
 - [`canary-sanity`](https://storage.googleapis.com/gitlab-qa-allure-reports/canary-sanity/master/index.html)
-- [`production`](https://storage.googleapis.com/gitlab-qa-allure-reports/production/master/index.html)
+- [`production`](https://storage.googleapis.com/gitlab-qa-allure-reports/production-full/master/index.html)
 - [`production-sanity`](https://storage.googleapis.com/gitlab-qa-allure-reports/production-sanity/master/index.html)
 
 ## How do I run the tests?
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index d91c53823e2..9410c2f07a5 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 532bb9fcdef..b272d23522e 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 02f32a031dc..c1bf3609b53 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 b86bb824ea1..f71a0b345e0 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 365cc7991d8..3b240d4cbc6 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 3aa7e945f53..de3636fa112 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: