chore: update slugs and reorder pages (#1447)

* chore: update page weight

* chore: rename pages and add aliases

* chore: backport to v0.48

* chore: backport to v0.47

.eslintignore

@@ -3,6 +3,7 @@ public/
 node_modules/
 docs/sources/get-started/run-cloud-tests-from-the-CLI.md
 docs/sources/get-started/run-your-first-tests.md
+/docs/sources/*/testing-guides/injecting-faults-with-xk6-disruptor/expose-your-application.md
 CONTRIBUTING_FILE_FORMAT.md
 src/data/markdown/docs/40 xk6-disruptor/01 Get started/01 First steps.md
 src/data/markdown/docs/40 xk6-disruptor/01 Get started/04 Expose Your Application.md

docs/sources/next/testing-guides/injecting-faults-with-xk6-disruptor/expose--your-application.md → docs/sources/next/testing-guides/injecting-faults-with-xk6-disruptor/expose-your-application.md

@@ -2,6 +2,8 @@
 title: 'Expose your application'
 excerpt: 'How to make your applications accessible from the test scripts.'
 weight: 04
+aliases:
+  - ./expose--your-application/
 ---
 
 # Expose your application
@@ -31,7 +33,7 @@ Until this issue is solved in `kubectl`, tests using port forwarding to access a
 
 The simplest way to accomplish this is to ensure the scenario that executes the load (#2) starts after the scenario that injects the faults (#1):
 
-```javascript
+```js
     scenarios: {
         disrupt: {   // #1 inject faults
             executor: 'shared-iterations',
@@ -62,25 +64,29 @@ If your cluster is deployed in a public cloud, check your cloud provider documen
 If the service that you want your tests to access is not defined as a load balancer, you can change the service type with the following command. The service will then receive an external IP.
 
 {{< code >}}
+
 ```bash
 kubectl -n <name space> patch svc <service name> -p '{"spec": {"type": "LoadBalancer"}}'
 ```
 
 ```windows-powershell
 kubectl -n <name space> patch svc <service name> -p '{\"spec\": {\"type\": \"LoadBalancer\"}}'
 ```
+
 {{< /code >}}
 
 You can retrieve the external IP address and store it in an environment variable (`SVC_IP` in this example) using the following command:
 
 {{< code >}}
+
 ```bash
 SVC_IP=$(kubectl -n <name space>  get svc <service name> --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
 ```
 
 ```windows-powershell
 $Env:SVC_IP=$(kubectl -n <name space>  get svc <service name> --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
 ```
+
 {{< /code >}}
 
 ### Configuring a LoadBalancer in Kind

docs/sources/v0.47.x/testing-guides/injecting-faults-with-xk6-disruptor/how--it-works.md → docs/sources/next/testing-guides/injecting-faults-with-xk6-disruptor/how-it-works.md

@@ -2,6 +2,8 @@
 title: 'How xk6-disruptor works'
 excerpt: 'A brief description of the components of the xk6-disruptor and how they work when inject faults in a target system.'
 weight: 05
+aliases:
+  - ./how--it-works/
 ---
 
 # How xk6-disruptor works

docs/sources/v0.48.x/using-k6/protocols/ssl-tls/online-certificate-status-protocol--ocsp.md → docs/sources/next/using-k6/protocols/ssl-tls/online-certificate-status-protocol-ocsp.md

@@ -2,6 +2,8 @@
 title: 'Online Certificate Status Protocol (OCSP)'
 excerpt: 'k6 supports OCSP stapling, receiving and parsing a stapled response as part of
 the TLS connection setup.'
+aliases:
+  - ./online-certificate-status-protocol--ocsp/
 ---
 
 ## What is OCSP?

docs/sources/next/using-k6/scenarios/concepts/arrival-rate-vu-allocation.md

@@ -1,7 +1,7 @@
 ---
 title: Arrival-rate VU allocation
 excerpt: How k6 allocates VUs in the open-model, arrival-rate executors
-weight: 02
+weight: 20
 ---
 
 # Arrival-rate VU allocation
@@ -21,7 +21,7 @@ In cloud tests, **`preAllocatedVUs` count against your subscription.**
 
 When planning a test, consider doing a trial initialization on a local machine to ensure you're allocating VUs efficiently.
 
- {{% /admonition %}}
+{{% /admonition %}}
 
 ## Pre-allocation in arrival-rate executors
 
@@ -65,9 +65,9 @@ the number of available `preAllocatedVUs` determines how many iterations k6 can
 k6 tries to reach the target iterations per second,
 and one of two things can happen:
 
-| If the executor       | Then..                                                                                                                                                  |
-| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Has enough VUs        | the extra VUs are "idle," ready to be used when needed.                                                                                                 |
+| If the executor       | Then..                                                                                                                                                                  |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Has enough VUs        | the extra VUs are "idle," ready to be used when needed.                                                                                                                 |
 | Has insufficient VUs. | k6 emits a [`dropped_iterations` metric](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/concepts/dropped-iterations) for each iteration that it can't run. |
 
 ## Iteration duration affects the necessary allocation
@@ -96,7 +96,7 @@ As dropped iterations can also indicate that the system performance is degrading
 In cloud tests, the number of `maxVUs` counts against your subscription,
 **overriding the number set by `preAllocatedVUs`**.
 
- {{% /admonition %}}
+{{% /admonition %}}
 
 The arrival-rate executors also have a `maxVUs` property.
 If you set it, k6 runs in this sequence:

docs/sources/next/using-k6/scenarios/concepts/dropped-iterations.md

@@ -1,7 +1,7 @@
 ---
 title: Dropped iterations
 excerpt: Explanations about how your scenario configuration or SUT performance can lead to dropped iterations
-weight: 03
+weight: 30
 ---
 
 # Dropped iterations

docs/sources/next/using-k6/scenarios/concepts/graceful-stop.md

@@ -1,7 +1,7 @@
 ---
 title: 'Graceful stop'
 excerpt: 'This option is available for all executors except externally-controlled and allows the user to specify a duration to wait before forcefully interrupting them.'
-weight: 01
+weight: 10
 ---
 
 # Graceful stop

docs/sources/v0.48.x/testing-guides/injecting-faults-with-xk6-disruptor/expose--your-application.md → docs/sources/v0.47.x/testing-guides/injecting-faults-with-xk6-disruptor/expose-your-application.md

@@ -2,6 +2,8 @@
 title: 'Expose your application'
 excerpt: 'How to make your applications accessible from the test scripts.'
 weight: 04
+aliases:
+  - ./expose--your-application/
 ---
 
 # Expose your application
@@ -31,7 +33,7 @@ Until this issue is solved in `kubectl`, tests using port forwarding to access a
 
 The simplest way to accomplish this is to ensure the scenario that executes the load (#2) starts after the scenario that injects the faults (#1):
 
-```javascript
+```js
     scenarios: {
         disrupt: {   // #1 inject faults
             executor: 'shared-iterations',
@@ -62,25 +64,29 @@ If your cluster is deployed in a public cloud, check your cloud provider documen
 If the service that you want your tests to access is not defined as a load balancer, you can change the service type with the following command. The service will then receive an external IP.
 
 {{< code >}}
+
 ```bash
 kubectl -n <name space> patch svc <service name> -p '{"spec": {"type": "LoadBalancer"}}'
 ```
 
 ```windows-powershell
 kubectl -n <name space> patch svc <service name> -p '{\"spec\": {\"type\": \"LoadBalancer\"}}'
 ```
+
 {{< /code >}}
 
 You can retrieve the external IP address and store it in an environment variable (`SVC_IP` in this example) using the following command:
 
 {{< code >}}
+
 ```bash
 SVC_IP=$(kubectl -n <name space>  get svc <service name> --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
 ```
 
 ```windows-powershell
 $Env:SVC_IP=$(kubectl -n <name space>  get svc <service name> --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
 ```
+
 {{< /code >}}
 
 ### Configuring a LoadBalancer in Kind

docs/sources/next/testing-guides/injecting-faults-with-xk6-disruptor/how--it-works.md → docs/sources/v0.47.x/testing-guides/injecting-faults-with-xk6-disruptor/how-it-works.md

@@ -2,6 +2,8 @@
 title: 'How xk6-disruptor works'
 excerpt: 'A brief description of the components of the xk6-disruptor and how they work when inject faults in a target system.'
 weight: 05
+aliases:
+  - ./how--it-works/
 ---
 
 # How xk6-disruptor works

docs/sources/v0.47.x/using-k6/protocols/ssl-tls/online-certificate-status-protocol--ocsp.md → docs/sources/v0.47.x/using-k6/protocols/ssl-tls/online-certificate-status-protocol-ocsp.md

@@ -2,6 +2,8 @@
 title: 'Online Certificate Status Protocol (OCSP)'
 excerpt: 'k6 supports OCSP stapling, receiving and parsing a stapled response as part of
 the TLS connection setup.'
+aliases:
+  - ./online-certificate-status-protocol--ocsp/
 ---
 
 ## What is OCSP?

docs/sources/v0.47.x/using-k6/scenarios/concepts/arrival-rate-vu-allocation.md

@@ -1,7 +1,7 @@
 ---
 title: Arrival-rate VU allocation
 excerpt: How k6 allocates VUs in the open-model, arrival-rate executors
-weight: 02
+weight: 20
 ---
 
 # Arrival-rate VU allocation
@@ -21,7 +21,7 @@ In cloud tests, **`preAllocatedVUs` count against your subscription.**
 
 When planning a test, consider doing a trial initialization on a local machine to ensure you're allocating VUs efficiently.
 
- {{% /admonition %}}
+{{% /admonition %}}
 
 ## Pre-allocation in arrival-rate executors
 
@@ -65,9 +65,9 @@ the number of available `preAllocatedVUs` determines how many iterations k6 can
 k6 tries to reach the target iterations per second,
 and one of two things can happen:
 
-| If the executor       | Then..                                                                                                                                                  |
-| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Has enough VUs        | the extra VUs are "idle," ready to be used when needed.                                                                                                 |
+| If the executor       | Then..                                                                                                                                                                  |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Has enough VUs        | the extra VUs are "idle," ready to be used when needed.                                                                                                                 |
 | Has insufficient VUs. | k6 emits a [`dropped_iterations` metric](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/concepts/dropped-iterations) for each iteration that it can't run. |
 
 ## Iteration duration affects the necessary allocation
@@ -96,7 +96,7 @@ As dropped iterations can also indicate that the system performance is degrading
 In cloud tests, the number of `maxVUs` counts against your subscription,
 **overriding the number set by `preAllocatedVUs`**.
 
- {{% /admonition %}}
+{{% /admonition %}}
 
 The arrival-rate executors also have a `maxVUs` property.
 If you set it, k6 runs in this sequence:

docs/sources/v0.47.x/using-k6/scenarios/concepts/dropped-iterations.md

@@ -1,7 +1,7 @@
 ---
 title: Dropped iterations
 excerpt: Explanations about how your scenario configuration or SUT performance can lead to dropped iterations
-weight: 03
+weight: 30
 ---
 
 # Dropped iterations

docs/sources/v0.47.x/using-k6/scenarios/concepts/graceful-stop.md

@@ -1,7 +1,7 @@
 ---
 title: 'Graceful stop'
 excerpt: 'This option is available for all executors except externally-controlled and allows the user to specify a duration to wait before forcefully interrupting them.'
-weight: 01
+weight: 10
 ---
 
 # Graceful stop

docs/sources/v0.47.x/testing-guides/injecting-faults-with-xk6-disruptor/expose--your-application.md → docs/sources/v0.48.x/testing-guides/injecting-faults-with-xk6-disruptor/expose-your-application.md

@@ -2,6 +2,8 @@
 title: 'Expose your application'
 excerpt: 'How to make your applications accessible from the test scripts.'
 weight: 04
+aliases:
+  - ./expose--your-application/
 ---
 
 # Expose your application
@@ -31,7 +33,7 @@ Until this issue is solved in `kubectl`, tests using port forwarding to access a
 
 The simplest way to accomplish this is to ensure the scenario that executes the load (#2) starts after the scenario that injects the faults (#1):
 
-```javascript
+```js
     scenarios: {
         disrupt: {   // #1 inject faults
             executor: 'shared-iterations',
@@ -62,25 +64,29 @@ If your cluster is deployed in a public cloud, check your cloud provider documen
 If the service that you want your tests to access is not defined as a load balancer, you can change the service type with the following command. The service will then receive an external IP.
 
 {{< code >}}
+
 ```bash
 kubectl -n <name space> patch svc <service name> -p '{"spec": {"type": "LoadBalancer"}}'
 ```
 
 ```windows-powershell
 kubectl -n <name space> patch svc <service name> -p '{\"spec\": {\"type\": \"LoadBalancer\"}}'
 ```
+
 {{< /code >}}
 
 You can retrieve the external IP address and store it in an environment variable (`SVC_IP` in this example) using the following command:
 
 {{< code >}}
+
 ```bash
 SVC_IP=$(kubectl -n <name space>  get svc <service name> --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
 ```
 
 ```windows-powershell
 $Env:SVC_IP=$(kubectl -n <name space>  get svc <service name> --output jsonpath='{.status.loadBalancer.ingress[0].ip}')
 ```
+
 {{< /code >}}
 
 ### Configuring a LoadBalancer in Kind

docs/sources/v0.48.x/testing-guides/injecting-faults-with-xk6-disruptor/how--it-works.md → docs/sources/v0.48.x/testing-guides/injecting-faults-with-xk6-disruptor/how-it-works.md

@@ -2,6 +2,8 @@
 title: 'How xk6-disruptor works'
 excerpt: 'A brief description of the components of the xk6-disruptor and how they work when inject faults in a target system.'
 weight: 05
+aliases:
+  - ./how--it-works/
 ---
 
 # How xk6-disruptor works

docs/sources/next/using-k6/protocols/ssl-tls/online-certificate-status-protocol--ocsp.md → docs/sources/v0.48.x/using-k6/protocols/ssl-tls/online-certificate-status-protocol-ocsp.md

@@ -2,6 +2,8 @@
 title: 'Online Certificate Status Protocol (OCSP)'
 excerpt: 'k6 supports OCSP stapling, receiving and parsing a stapled response as part of
 the TLS connection setup.'
+aliases:
+  - ./online-certificate-status-protocol--ocsp/
 ---
 
 ## What is OCSP?

docs/sources/v0.48.x/using-k6/scenarios/concepts/arrival-rate-vu-allocation.md

@@ -1,7 +1,7 @@
 ---
 title: Arrival-rate VU allocation
 excerpt: How k6 allocates VUs in the open-model, arrival-rate executors
-weight: 02
+weight: 20
 ---
 
 # Arrival-rate VU allocation
@@ -21,7 +21,7 @@ In cloud tests, **`preAllocatedVUs` count against your subscription.**
 
 When planning a test, consider doing a trial initialization on a local machine to ensure you're allocating VUs efficiently.
 
- {{% /admonition %}}
+{{% /admonition %}}
 
 ## Pre-allocation in arrival-rate executors
 
@@ -65,9 +65,9 @@ the number of available `preAllocatedVUs` determines how many iterations k6 can
 k6 tries to reach the target iterations per second,
 and one of two things can happen:
 
-| If the executor       | Then..                                                                                                                                                  |
-| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Has enough VUs        | the extra VUs are "idle," ready to be used when needed.                                                                                                 |
+| If the executor       | Then..                                                                                                                                                                  |
+| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Has enough VUs        | the extra VUs are "idle," ready to be used when needed.                                                                                                                 |
 | Has insufficient VUs. | k6 emits a [`dropped_iterations` metric](https://grafana.com/docs/k6/<K6_VERSION>/using-k6/scenarios/concepts/dropped-iterations) for each iteration that it can't run. |
 
 ## Iteration duration affects the necessary allocation
@@ -96,7 +96,7 @@ As dropped iterations can also indicate that the system performance is degrading
 In cloud tests, the number of `maxVUs` counts against your subscription,
 **overriding the number set by `preAllocatedVUs`**.
 
- {{% /admonition %}}
+{{% /admonition %}}
 
 The arrival-rate executors also have a `maxVUs` property.
 If you set it, k6 runs in this sequence:

docs/sources/v0.48.x/using-k6/scenarios/concepts/dropped-iterations.md

@@ -1,7 +1,7 @@
 ---
 title: Dropped iterations
 excerpt: Explanations about how your scenario configuration or SUT performance can lead to dropped iterations
-weight: 03
+weight: 30
 ---
 
 # Dropped iterations

docs/sources/v0.48.x/using-k6/scenarios/concepts/graceful-stop.md

@@ -1,7 +1,7 @@
 ---
 title: 'Graceful stop'
 excerpt: 'This option is available for all executors except externally-controlled and allows the user to specify a duration to wait before forcefully interrupting them.'
-weight: 01
+weight: 10
 ---
 
 # Graceful stop