Merge branch 'docs-links-updates-1' into 'master'

Update links in development docs

See merge request gitlab-org/gitlab!57089

doc/.vale/gitlab/spelling-exceptions.txt

@@ -257,6 +257,7 @@ https
 idempotence
 idmapper
 Iglu
+Immer
 inclusivity
 Ingress
 initializer

doc/administration/feature_flags.md

@@ -13,7 +13,7 @@ to deploy features in an early stage of development so that they can be
 incrementally rolled out.
 
 Before making them permanently available, features can be deployed behind
-flags for a [number of reasons](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#when-to-use-feature-flags), such as:
+flags for a [number of reasons](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags), such as:
 
 - To test the feature.
 - To get feedback from users and customers while in an early stage of the development of the feature.

doc/development/code_review.md

@@ -188,8 +188,7 @@ Avoid:
 - Excessively mentioning maintainers through email or Slack (if the maintainer is reachable
 through Slack). If you can't assign a merge request, `@` mentioning a maintainer in a comment is acceptable and in all other cases assigning the merge request is sufficient.
 
-This
-[saves reviewers time and helps authors catch mistakes earlier](https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/index.html#__RefHeading__97_174136755).
+This saves reviewers time and helps authors catch mistakes earlier.
 
 ### The responsibility of the reviewer
 

doc/development/database/index.md

@@ -18,7 +18,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 - [Understanding EXPLAIN plans](../understanding_explain_plans.md)
 - [explain.depesz.com](https://explain.depesz.com/) or [explain.dalibo.com](https://explain.dalibo.com/) for visualizing the output of `EXPLAIN`
-- [pgFormatter](http://sqlformat.darold.net/) a PostgreSQL SQL syntax beautifier
+- [pgFormatter](https://sqlformat.darold.net/) a PostgreSQL SQL syntax beautifier
 
 ## Migrations
 

doc/development/documentation/feature_flags.md

@@ -20,7 +20,7 @@ must be documented. For context, see the
 
 ## Criteria
 
-According to the process of [deploying GitLab features behind feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle):
+According to the process of [deploying GitLab features behind feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/):
 
 > - _By default, feature flags should be off._
 > - _Feature flags should remain in the codebase for a short period as possible to reduce the need for feature flag accounting._

doc/development/documentation/testing.md

@@ -166,7 +166,7 @@ You can use markdownlint:
 
 ### Vale
 
-[Vale](https://errata-ai.gitbook.io/vale/) is a grammar, style, and word usage linter for the
+[Vale](https://docs.errata.ai/vale/about/) is a grammar, style, and word usage linter for the
 English language. Vale's configuration is stored in the
 [`.vale.ini`](https://gitlab.com/gitlab-org/gitlab/blob/master/.vale.ini) file located in the root
 directory of projects.
@@ -188,7 +188,7 @@ This configuration is also used in build pipelines, where
 
 You can use Vale:
 
-- [On the command line](https://errata-ai.gitbook.io/vale/getting-started/usage).
+- [On the command line](https://docs.errata.ai/vale/cli).
 - [In a code editor](#configure-editors).
 - [In a Git hook](#configure-pre-push-hooks). Vale only reports errors in the Git hook (the same
   configuration as the CI/CD pipelines), and does not report suggestions or warnings.
@@ -333,4 +333,4 @@ document:
 Whenever possible, exclude only the problematic rule and line(s).
 
 For more information, see
-[Vale's documentation](https://errata-ai.gitbook.io/vale/getting-started/markup#markup-based-configuration).
+[Vale's documentation](https://docs.errata.ai/vale/scoping#markup-based-configuration).

doc/development/fe_guide/graphql.md

@@ -43,13 +43,9 @@ can help you learn how to integrate Vue Apollo.
 
 For other use cases, check out the [Usage outside of Vue](#usage-outside-of-vue) section.
 
-<!-- vale gitlab.Spelling = NO -->
-
-We use [Immer](https://immerjs.github.io/immer/docs/introduction) for immutable cache updates;
+We use [Immer](https://immerjs.github.io/immer/) for immutable cache updates;
 see [Immutability and cache updates](#immutability-and-cache-updates) for more information.
 
-<!-- vale gitlab.Spelling = YES -->
-
 ### Tooling
 
 <!-- vale gitlab.Spelling = NO -->
@@ -173,14 +169,10 @@ const primaryKeyId = getIdFromGraphQLId(data.id);
 From Apollo version 3.0.0 all the cache updates need to be immutable. It needs to be replaced entirely
 with a **new and updated** object.
 
-<!-- vale gitlab.Spelling = NO -->
-
 To facilitate the process of updating the cache and returning the new object we
-use the library [Immer](https://immerjs.github.io/immer/docs/introduction).
+use the library [Immer](https://immerjs.github.io/immer/).
 When possible, follow these conventions:
 
-<!-- vale gitlab.Spelling = YES -->
-
 - The updated cache is named `data`.
 - The original cache data is named `sourceData`.
 

doc/development/fe_guide/style/vue.md

@@ -615,7 +615,7 @@ component state wherever possible. Instead, set the component's
     ```
 
 1. When asserting multiple props, check the deep equality of the `props()` object with
-[`toEqual`](https://jestjs.io/docs/en/expect#toequalvalue):
+[`toEqual`](https://jestjs.io/docs/expect#toequalvalue):
 
     ```javascript
     // good
@@ -632,8 +632,8 @@ component state wherever possible. Instead, set the component's
     ```
 
 1. If you are only interested in some of the props, you can use
-[`toMatchObject`](https://jestjs.io/docs/en/expect#tomatchobjectobject). Prefer `toMatchObject`
-over [`expect.objectContaining`](https://jestjs.io/docs/en/expect#expectobjectcontainingobject):
+[`toMatchObject`](https://jestjs.io/docs/expect#tomatchobjectobject). Prefer `toMatchObject`
+over [`expect.objectContaining`](https://jestjs.io/docs/expect#expectobjectcontainingobject):
 
     ```javascript
     // good

doc/development/feature_flags/controls.md

@@ -36,7 +36,7 @@ easier to measure the impact of both separately.
 
 The GitLab feature library (using
 [Flipper](https://github.com/jnunemaker/flipper), and covered in the [Feature
-Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle) guide) supports rolling out changes to a percentage of
+Flags process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) guide) supports rolling out changes to a percentage of
 time to users. This in turn can be controlled using [GitLab ChatOps](../../ci/chatops/index.md).
 
 For an up to date list of feature flag commands please see [the source
@@ -281,7 +281,7 @@ To remove a feature flag, open **one merge request** to make the changes. In the
 1. Add the ~"feature flag" label so release managers are aware the changes are hidden behind a feature flag.
 1. If the merge request has to be picked into a stable branch, add the
    appropriate `~"Pick into X.Y"` label, for example `~"Pick into 13.0"`.
-   See [the feature flag process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#including-a-feature-behind-feature-flag-in-the-final-release)
+   See [the feature flag process](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#including-a-feature-behind-feature-flag-in-the-final-release)
    for further details.
 1. Remove all references to the feature flag from the codebase, including tests.
 1. Remove the YAML definition for the feature from the repository.

doc/development/integrations/secure_partner_integration.md

@@ -71,12 +71,12 @@ best place to integrate your own product and its results into GitLab.
 This section describes the steps you need to complete to onboard as a partner
 and complete an integration with the Secure stage.
 
-1. Read about our [partnerships](https://about.gitlab.com/partners/integrate/).
+1. Read about our [partnerships](https://about.gitlab.com/partners/technology-partners/integrate/).
 1. [Create an issue](https://gitlab.com/gitlab-com/alliances/alliances/-/issues/new?issuable_template=new_partner)
    using our new partner issue template to begin the discussion.
 1. Get a test account to begin developing your integration. You can
-   request a [GitLab.com Subscription Sandbox](https://about.gitlab.com/partners/integrate/#gitlabcom-subscription-sandbox-request)
-   or an [EE Developer License](https://about.gitlab.com/partners/integrate/#requesting-ee-dev-license-for-rd).
+   request a [GitLab.com Subscription Sandbox](https://about.gitlab.com/partners/technology-partners/integrate/#gitlabcom-subscription-sandbox-request)
+   or an [EE Developer License](https://about.gitlab.com/partners/technology-partners/integrate/#requesting-ultimate-dev-license-for-rd).
 1. Provide a [pipeline job](../../development/pipelines.md)
    template that users could integrate into their own GitLab pipelines.
 1. Create a report artifact with your pipeline jobs.
@@ -105,10 +105,10 @@ and complete an integration with the Secure stage.
      interface.
 1. Demo the integration to GitLab:
    - After you have tested and are ready to demo your integration please
-     [reach out](https://about.gitlab.com/partners/integrate/) to us. If you
+     [reach out](https://about.gitlab.com/partners/technology-partners/integrate/) to us. If you
      skip this step you won't be able to do supported marketing.
 1. Begin doing supported marketing of your GitLab integration.
-   - Work with our [partner team](https://about.gitlab.com/partners/integrate/)
+   - Work with our [partner team](https://about.gitlab.com/partners/technology-partners/integrate/)
      to support your go-to-market as appropriate.
    - Examples of supported marketing could include being listed on our [Security Partner page](https://about.gitlab.com/partners/#security),
      doing an [Unfiltered blog post](https://about.gitlab.com/handbook/marketing/blog/unfiltered/),

doc/development/merge_request_performance_guidelines.md

@@ -459,7 +459,7 @@ Performance deficiencies should be addressed right away after we merge initial
 changes.
 
 Read more about when and how feature flags should be used in
-[Feature flags in GitLab development](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle#feature-flags-in-gitlab-development).
+[Feature flags in GitLab development](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flags-in-gitlab-development).
 
 ## Storage
 

doc/development/new_fe_guide/tips.md

@@ -27,7 +27,7 @@ Your feature flag can now be:
 ### More on feature flags
 
 - [Deleting a feature flag](../../api/features.md#delete-a-feature)
-- [Manage feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle)
+- [Manage feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/)
 - [Feature flags API](../../api/features.md)
 
 ## Running tests locally

doc/development/testing_guide/frontend_testing.md

@@ -55,8 +55,8 @@ which have to be stubbed.
 - Because Jest runs in a Node.js environment, it uses [jsdom](https://github.com/jsdom/jsdom) by default. See also its [limitations](#limitations-of-jsdom) below.
 - Jest does not have access to Webpack loaders or aliases.
   The aliases used by Jest are defined in its [own configuration](https://gitlab.com/gitlab-org/gitlab/blob/master/jest.config.js).
-- All calls to `setTimeout` and `setInterval` are mocked away. See also [Jest Timer Mocks](https://jestjs.io/docs/en/timer-mocks).
-- `rewire` is not required because Jest supports mocking modules. See also [Manual Mocks](https://jestjs.io/docs/en/manual-mocks).
+- All calls to `setTimeout` and `setInterval` are mocked away. See also [Jest Timer Mocks](https://jestjs.io/docs/timer-mocks).
+- `rewire` is not required because Jest supports mocking modules. See also [Manual Mocks](https://jestjs.io/docs/manual-mocks).
 - No [context object](https://jasmine.github.io/tutorials/your_first_suite#section-The_%3Ccode%3Ethis%3C/code%3E_keyword) is passed to tests in Jest.
   This means sharing `this.something` between `beforeEach()` and `it()` for example does not work.
   Instead you should declare shared variables in the context that they are needed (via `const` / `let`).
@@ -78,7 +78,7 @@ See also the issue for [support running Jest tests in browsers](https://gitlab.c
 
 ### Debugging Jest tests
 
-Running `yarn jest-debug` runs Jest in debug mode, allowing you to debug/inspect as described in the [Jest docs](https://jestjs.io/docs/en/troubleshooting#tests-are-failing-and-you-don-t-know-why).
+Running `yarn jest-debug` runs Jest in debug mode, allowing you to debug/inspect as described in the [Jest docs](https://jestjs.io/docs/troubleshooting#tests-are-failing-and-you-don-t-know-why).
 
 ### Timeout error
 
@@ -376,7 +376,7 @@ Sometimes we have to test time-sensitive code. For example, recurring events tha
 
 If the application itself is waiting for some time, mock await the waiting. In Jest this is already
 [done by default](https://gitlab.com/gitlab-org/gitlab/blob/a2128edfee799e49a8732bfa235e2c5e14949c68/jest.config.js#L47)
-(see also [Jest Timer Mocks](https://jestjs.io/docs/en/timer-mocks)). In Karma you can use the
+(see also [Jest Timer Mocks](https://jestjs.io/docs/timer-mocks)). In Karma you can use the
 [Jasmine mock clock](https://jasmine.github.io/api/2.9/Clock.html).
 
 ```javascript
@@ -564,9 +564,9 @@ This is however not entirely true as the `destroy` method does not remove everyt
 
 #### Prefer `toBe` over `toEqual` when comparing primitive values
 
-Jest has [`toBe`](https://jestjs.io/docs/en/expect#tobevalue) and
-[`toEqual`](https://jestjs.io/docs/en/expect#toequalvalue) matchers.
-As [`toBe`](https://jestjs.io/docs/en/expect#tobevalue) uses
+Jest has [`toBe`](https://jestjs.io/docs/expect#tobevalue) and
+[`toEqual`](https://jestjs.io/docs/expect#toequalvalue) matchers.
+As [`toBe`](https://jestjs.io/docs/expect#tobevalue) uses
 [`Object.is`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/is)
 to compare values, it's faster (by default) than using `toEqual`.
 While the latter eventually falls back to leverage [`Object.is`](https://github.com/facebook/jest/blob/master/packages/expect/src/jasmineUtils.ts#L91),
@@ -588,7 +588,7 @@ expect(foo).toBe(1);
 
 Jest provides useful matchers like `toHaveLength` or `toBeUndefined` to make your tests more
 readable and to produce more understandable error messages. Check their docs for the
-[full list of matchers](https://jestjs.io/docs/en/expect#methods).
+[full list of matchers](https://jestjs.io/docs/expect#methods).
 
 Examples:
 
@@ -719,7 +719,7 @@ TBU
 Jasmine provides stubbing and mocking capabilities. There are some subtle differences in how to use it within Karma and Jest.
 
 Stubs or spies are often used synonymously. In Jest it's quite easy thanks to the `.spyOn` method.
-[Official docs](https://jestjs.io/docs/en/jest-object#jestspyonobject-methodname)
+[Official docs](https://jestjs.io/docs/jest-object#jestspyonobject-methodname)
 The more challenging part are mocks, which can be used for functions or even dependencies.
 
 ### Manual module mocks
@@ -728,12 +728,12 @@ Manual mocks are used to mock modules across the entire Jest environment. This i
 unit testing by mocking out modules which cannot be easily consumed in our test environment.
 
 > **WARNING:** Do not use manual mocks if a mock should not be consistently applied in every spec (i.e. it's only needed by a few specs).
-> Instead, consider using [`jest.mock(..)`](https://jestjs.io/docs/en/jest-object#jestmockmodulename-factory-options)
+> Instead, consider using [`jest.mock(..)`](https://jestjs.io/docs/jest-object#jestmockmodulename-factory-options)
 > (or a similar mocking function) in the relevant spec file.
 
 #### Where should I put manual mocks?
 
-Jest supports [manual module mocks](https://jestjs.io/docs/en/manual-mocks) by placing a mock in a `__mocks__/` directory next to the source module
+Jest supports [manual module mocks](https://jestjs.io/docs/manual-mocks) by placing a mock in a `__mocks__/` directory next to the source module
 (e.g. `app/assets/javascripts/ide/__mocks__`). **Don't do this.** We want to keep all of our test-related code in one place (the `spec/` folder).
 
 If a manual mock is needed for a `node_modules` package, use the `spec/frontend/__mocks__` folder. Here's an example of
@@ -766,7 +766,7 @@ Global mocks introduce magic and technically can reduce test coverage. When mock
 
 ### Additional mocking techniques
 
-Consult the [official Jest docs](https://jestjs.io/docs/en/jest-object#mock-modules) for a full overview of the available mocking features.
+Consult the [official Jest docs](https://jestjs.io/docs/jest-object#mock-modules) for a full overview of the available mocking features.
 
 ## Running Frontend Tests
 
@@ -939,8 +939,8 @@ it('uses some HTML element', () => {
 Similar to [RSpec's parameterized tests](best_practices.md#table-based--parameterized-tests),
 Jest supports data-driven tests for:
 
-- Individual tests using [`test.each`](https://jestjs.io/docs/en/api#testeachtable-name-fn-timeout) (aliased to `it.each`).
-- Groups of tests using [`describe.each`](https://jestjs.io/docs/en/api#describeeachtable-name-fn-timeout).
+- Individual tests using [`test.each`](https://jestjs.io/docs/api#testeachtable-name-fn-timeout) (aliased to `it.each`).
+- Groups of tests using [`describe.each`](https://jestjs.io/docs/api#describeeachtable-name-fn-timeout).
 
 These can be useful for reducing repetition within tests. Each option can take an array of
 data values or a tagged template literal.
@@ -1189,7 +1189,7 @@ You can download any older version of Firefox from the releases FTP server, <htt
 
 ## Snapshots
 
-By now you've probably heard of [Jest snapshot tests](https://jestjs.io/docs/en/snapshot-testing) and why they are useful for various reasons.
+By now you've probably heard of [Jest snapshot tests](https://jestjs.io/docs/snapshot-testing) and why they are useful for various reasons.
 To use them within GitLab, there are a few guidelines that should be highlighted:
 
 - Treat snapshots as code
@@ -1199,7 +1199,7 @@ To use them within GitLab, there are a few guidelines that should be highlighted
 Think of a snapshot test as a simple way to store a raw `String` representation of what you've put into the item being tested. This can be used to evaluate changes in a component, a store, a complex piece of generated output, etc. You can see more in the list below for some recommended `Do's and Don'ts`.
 While snapshot tests can be a very powerful tool. They are meant to supplement, not to replace unit tests.
 
-Jest provides a great set of docs on [best practices](https://jestjs.io/docs/en/snapshot-testing#best-practices) that we should keep in mind when creating snapshots.
+Jest provides a great set of docs on [best practices](https://jestjs.io/docs/snapshot-testing#best-practices) that we should keep in mind when creating snapshots.
 
 ### How does a snapshot work?
 
@@ -1207,7 +1207,7 @@ A snapshot is purely a stringified version of what you ask to be tested on the l
 
 Should the outcome of your spec be different from what is in the generated snapshot file, you'll be notified about it by a failing test in your test suite.
 
-Find all the details in Jests official documentation [https://jestjs.io/docs/en/snapshot-testing](https://jestjs.io/docs/en/snapshot-testing)
+Find all the details in Jests official documentation [https://jestjs.io/docs/snapshot-testing](https://jestjs.io/docs/snapshot-testing)
 
 ### How to take a snapshot