Update links that include misc path (#2199)

* Update links that include `misc` path

* Skip code block

* Apply to previous versions

Author: heitortsergent

docs/sources/k6/next/get-started/resources.md

@@ -42,4 +42,4 @@ If you want to run tests with high loads, you can deploy and host them on your i
 - [Kubernetes Operator](https://k6.io/blog/running-distributed-tests-on-k8s/). Distribute test execution across a Kubernetes cluster.
 - [xk6 extensions](https://grafana.com/docs/k6/<K6_VERSION>/extensions). Custom k6 binaries to support the tool you need.
 - [Use TypeScript in k6 scripts](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/javascript-typescript-compatibility-mode/)
-- [Integrations](https://grafana.com/docs/k6/<K6_VERSION>/misc/integrations)
+- [Integrations](https://grafana.com/docs/k6/<K6_VERSION>/reference/integrations)

docs/sources/k6/next/testing-guides/automated-performance-testing.md

@@ -40,7 +40,7 @@ Without automation, the lack of a shared framework often leads to isolated and s
 
 Automation often refers to running tests with pass/fail conditions as part of the release process within CI/CD pipelines. However, not all performance tests are suited for CI/CD workflows, nor are they solely about providing a Pass/Fail (green/red) status and acting as a release gatekeeper.
 
-[Automation into CI/CD pipelines](https://grafana.com/docs/k6/<K6_VERSION>/misc/integrations/#continuous-integration-and-continuous-delivery) is an option, but it's not the only method to schedule the execution of performance tests. When creating a performance testing plan, it's important to remember that there are different ways to run performance tests in a frequent basis:
+[Automation into CI/CD pipelines](https://grafana.com/docs/k6/<K6_VERSION>/reference/integrations/#continuous-integration-and-continuous-delivery) is an option, but it's not the only method to schedule the execution of performance tests. When creating a performance testing plan, it's important to remember that there are different ways to run performance tests in a frequent basis:
 
 - Cron and cron job runners.
 - Cloud testing tools, such as [scheduling in Grafana Cloud k6](https://grafana.com/docs/grafana-cloud/testing/k6/author-run/schedule-a-test/).

docs/sources/k6/next/testing-guides/running-distributed-tests.md

@@ -10,15 +10,15 @@ It has already been established that k6 can [run large load tests](https://grafa
 
 Several reasons why you may wish to run a distributed test include:
 
-- Your [system under test](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#system-under-test) (SUT) should be accessed from multiple IP addresses.
+- Your [system under test](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#system-under-test) (SUT) should be accessed from multiple IP addresses.
 - A fully optimized node cannot produce the load required by your extremely large test.
 - Kubernetes is already your preferred operations environment.
 
 For scenarios such as these, we've created the [k6-operator](https://github.com/grafana/k6-operator).
 
 ## Introducing k6-operator
 
-[k6-operator](https://github.com/grafana/k6-operator) is an implementation of the [operator pattern](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#operator-pattern) in Kubernetes, defining [custom resources](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#custom-resource) in Kubernetes.
+[k6-operator](https://github.com/grafana/k6-operator) is an implementation of the [operator pattern](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#operator-pattern) in Kubernetes, defining [custom resources](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#custom-resource) in Kubernetes.
 The intent is to automate tasks that a _human operator_ would normally do; tasks like provisioning new application components, changing configurations, or resolving run-time issues.
 
 The k6-operator defines the custom `TestRun` resource type and listens for changes to, or creation of, `TestRun` objects.
@@ -193,7 +193,7 @@ To learn more about creating `PersistentVolume` and `PersistentVolumeClaim` reso
 During [installation](#1-install-the-operator), the `TestRun` [Custom Resource definition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) was added to the Kubernetes API.
 The data we provide in the custom resource `TestRun` object should contain all the information necessary for the k6-operator to start a distributed load test.
 
-Specifically, the main elements defined within the `TestRun` object relate to the name and location of the test script to run, and the amount of [parallelism](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#parallelism) to utilize.
+Specifically, the main elements defined within the `TestRun` object relate to the name and location of the test script to run, and the amount of [parallelism](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#parallelism) to utilize.
 
 {{< admonition type="note" >}}
 
@@ -206,7 +206,7 @@ The following examples will show some common variations for the custom resource:
 
 ### Script in a ConfigMap
 
-When the test script to be executed is contained within a `ConfigMap` resource, we specify the script details within the `configMap` block of [YAML](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#yaml).
+When the test script to be executed is contained within a `ConfigMap` resource, we specify the script details within the `configMap` block of [YAML](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#yaml).
 The `name` is the name of the ConfigMap and the `file` is the key-value for the entry.
 
 Let's create the file `run-k6-from-configmap.yaml` with the following content:
@@ -233,7 +233,7 @@ We created the ConfigMap named `my-test`.
 The test script content was added to the map using the filename as the key-value, therefore the `file` value is `test.js`.
 
 The amount of `parallelism` is up to you; how many pods do you want to split the test amongst?
-The operator will split the workload between the pods using [execution segments](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#execution-segment).
+The operator will split the workload between the pods using [execution segments](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#execution-segment).
 
 {{< admonition type="caution" >}}
 
@@ -278,7 +278,7 @@ Not everything should be included directly in your scripts.
 Well written scripts will allow for variability to support multiple scenarios and to avoid hard-coding values that tend to change.
 These could be anything from passwords to target urls, in addition to system options.
 
-We can pass this data as [environment variables](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#environment-variables) for use with each pod executing your script.
+We can pass this data as [environment variables](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#environment-variables) for use with each pod executing your script.
 This can be defined explicitly within the `TestRun` resource, or by referencing a `ConfigMap` or `Secret`.
 
 {{< code >}}
@@ -346,7 +346,7 @@ spec:
 
 {{< /code >}}
 
-With the above arguments, we're adding a [test-wide custom tag](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/tags-and-groups#test-wide-tags) to metrics and changing the output format of logs to [JSON](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#json).
+With the above arguments, we're adding a [test-wide custom tag](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/tags-and-groups#test-wide-tags) to metrics and changing the output format of logs to [JSON](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#json).
 
 {{< admonition type="note" >}}
 

docs/sources/k6/next/testing-guides/running-large-tests.md

@@ -13,10 +13,10 @@ Maximizing the load a machine generates is a multi-faceted process, which includ
 - Changing operating system settings to increase the default network and user limits.
 - Monitoring the load-generator machine to ensure adequate resource usage.
 - Designing efficient tests, with attention to scripting, k6 options, and file uploads.
-- Monitoring the test run to detect errors logged by k6, which could indicate limitations of the load generator machine or the [system under test](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#system-under-test) (SUT).
+- Monitoring the test run to detect errors logged by k6, which could indicate limitations of the load generator machine or the [system under test](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#system-under-test) (SUT).
 
 A single k6 process efficiently uses all CPU cores on a load generator machine. Depending on the available resources, and with the guidelines described in this document, a single instance of k6 can run 30,000-40,000 simultaneous users (VUs).
-In some cases, this number of VUs can generate up to 300,000 HTTP [requests per second](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#requests-per-second) (RPS).
+In some cases, this number of VUs can generate up to 300,000 HTTP [requests per second](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#requests-per-second) (RPS).
 
 Unless you need more than 100,000-300,000 requests per second (6-12M requests per minute), a single instance of k6 is likely sufficient for your needs.
 Read on to learn about how to get the most load from a single machine.
@@ -109,7 +109,7 @@ As the test runs, these are good indicators to monitor:
 ## Error handling should be resilient
 
 When running [large stress tests](https://grafana.com/docs/k6/<K6_VERSION>/testing-guides/test-types/stress-testing), your script shouldn't assume anything about the HTTP response.
-An oversight of some scripts is to test with only the [happy path](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#happy-path 'The default behavior that happens when the system returns no errors') in mind.
+An oversight of some scripts is to test with only the [happy path](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#happy-path 'The default behavior that happens when the system returns no errors') in mind.
 
 For example, in k6 scripts, we often see something like this _happy path_ check:
 
@@ -351,7 +351,7 @@ k6 run --execution-segment "3/4:1"     --execution-segment-sequence "0,1/4,2/4,3
 
 However, at this moment, the distributed execution mode of k6 is not entirely functional. The current limitations are:
 
-- k6 does not provide the functionality of a "primary" instance to coordinate the distributed execution of the test. Alternatively, you can use the [k6 REST API](https://grafana.com/docs/k6/<K6_VERSION>/misc/k6-rest-api) and [`--paused`](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/k6-options/reference#paused) to synchronize the multiple k6 instances' execution.
+- k6 does not provide the functionality of a "primary" instance to coordinate the distributed execution of the test. Alternatively, you can use the [k6 REST API](https://grafana.com/docs/k6/<K6_VERSION>/reference/k6-rest-api) and [`--paused`](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/k6-options/reference#paused) to synchronize the multiple k6 instances' execution.
 - Each k6 instance evaluates [Thresholds](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/thresholds) independently - excluding the results of the other k6 instances. If you want to disable the threshold execution, use [`--no-thresholds`](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/k6-options/reference#no-thresholds).
 - k6 reports the metrics individually for each instance. Depending on how you store the load test results, you'll have to aggregate some metrics to calculate them correctly.
 

docs/sources/k6/next/using-k6/environment-variables.md

@@ -7,7 +7,7 @@ weight: 1300
 # Environment variables
 
 Often, scripts need only minor tweaks to be reusable in different contexts.
-Rather than creating several separate scripts for these different contexts or environments, you can use [environment variables](https://grafana.com/docs/k6/<K6_VERSION>/misc/glossary#environment-variables) to make parts of your script tweakable.
+Rather than creating several separate scripts for these different contexts or environments, you can use [environment variables](https://grafana.com/docs/k6/<K6_VERSION>/reference/glossary#environment-variables) to make parts of your script tweakable.
 
 You can use environment variables for two main purposes:
 

docs/sources/k6/next/using-k6/javascript-typescript-compatibility-mode.md

@@ -108,4 +108,4 @@ The examples below demonstrate the use of Babel with bundlers like [Webpack](htt
 
 - [Running large tests](https://grafana.com/docs/k6/<K6_VERSION>/testing-guides/running-large-tests): Optimize k6 for better performance.
 - [k6 Modules](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/modules): Different options to import modules in k6.
-- [k6 Archive Command](https://grafana.com/docs/k6/<K6_VERSION>/misc/archive): The `k6 archive` command bundles all k6 test dependencies into a `tar` file, which can then be used for execution. It may also reduce the execution startup time.
+- [k6 Archive Command](https://grafana.com/docs/k6/<K6_VERSION>/reference/archive): The `k6 archive` command bundles all k6 test dependencies into a `tar` file, which can then be used for execution. It may also reduce the execution startup time.

docs/sources/k6/next/using-k6/k6-options/reference.md

@@ -92,7 +92,7 @@ and `k6 cloud run ...`, which you can use to override options specified in the c
 Address of the API server. When executing scripts with `k6 run`, an HTTP server with a REST API is spun up,
 which can be used to control some of the parameters of the test execution.
 
-By default, the server listens on `localhost:6565`. Read more on [k6 REST API](https://grafana.com/docs/k6/<K6_VERSION>/misc/k6-rest-api). You can disable the HTTP server by setting the address value to an empty string, for example: `k6 run -a '' script.js`.
+By default, the server listens on `localhost:6565`. Read more on [k6 REST API](https://grafana.com/docs/k6/<K6_VERSION>/reference/k6-rest-api). You can disable the HTTP server by setting the address value to an empty string, for example: `k6 run -a '' script.js`.
 
 | Env | CLI               | Code / Config file | Default          |
 | --- | ----------------- | ------------------ | ---------------- |

docs/sources/k6/next/using-k6/scenarios/executors/_index.md

@@ -12,6 +12,8 @@ The executor that you choose depends on the goals of your test and the type of t
 Define the executor in `executor` key of the scenario object.
 The value is the executor name separated by hyphens.
 
+<!-- md-k6:skip -->
+
 ```javascript
 export const options = {
   scenarios: {
@@ -36,7 +38,7 @@ The following table lists all k6 executors and links to their documentation.
 | [Ramping VUs](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/executors/ramping-vus)                     | `ramping-vus`           | A variable number of VUs execute as many<br/> iterations as possible for a specified amount of time.                                                                                       |
 | [Constant Arrival Rate](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/executors/constant-arrival-rate) | `constant-arrival-rate` | A fixed number of iterations are executed<br/> in a specified period of time.                                                                                                              |
 | [Ramping Arrival Rate](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/executors/ramping-arrival-rate)   | `ramping-arrival-rate`  | A variable number of iterations are <br/> executed in a specified period of time.                                                                                                          |
-| [Externally Controlled](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/executors/externally-controlled) | `externally-controlled` | Control and scale execution at runtime<br/> via [k6's REST API](https://grafana.com/docs/k6/<K6_VERSION>/misc/k6-rest-api) or the [CLI](https://k6.io/blog/how-to-control-a-live-k6-test). |
+| [Externally Controlled](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/executors/externally-controlled) | `externally-controlled` | Control and scale execution at runtime<br/> via [k6's REST API](https://grafana.com/docs/k6/<K6_VERSION>/reference/k6-rest-api) or the [CLI](https://k6.io/blog/how-to-control-a-live-k6-test). |
 
 {{< admonition type="note" >}}
 

docs/sources/k6/next/using-k6/scenarios/executors/externally-controlled.md

@@ -6,7 +6,7 @@ weight: 07
 
 # Externally controlled
 
-Control and scale execution at runtime via [k6's REST API](https://grafana.com/docs/k6/<K6_VERSION>/misc/k6-rest-api) or
+Control and scale execution at runtime via [k6's REST API](https://grafana.com/docs/k6/<K6_VERSION>/reference/k6-rest-api) or
 the [CLI](https://k6.io/blog/how-to-control-a-live-k6-test).
 
 Previously, the `pause`, `resume`, and `scale` CLI commands were used to globally control

docs/sources/k6/next/using-k6/tags-and-groups.md

@@ -312,7 +312,7 @@ Groups do the following tasks internally:
 - When a taggable resource—a check, request, or custom metric—runs within a group, k6 sets the tag `group` with the current group name.
   For more info, refer to the [Tags section](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/tags-and-groups#tags).
 
-Both options, the `group_duration` metric and `group tagging`, could help you analyze and visualize complex test results. Check out how they work in your [k6 result output](https://grafana.com/docs/k6/<K6_VERSION>/misc/integrations#result-store-and-visualization).
+Both options, the `group_duration` metric and `group tagging`, could help you analyze and visualize complex test results. Check out how they work in your [k6 result output](https://grafana.com/docs/k6/<K6_VERSION>/reference/integrations#result-store-and-visualization).
 
 ### Discouraged: one group per request