Fixing broken relative links

Author: jschalz

docs/pages/configuration/dependencies/basics.mdx

@@ -25,7 +25,7 @@ Dependencies for DevSpace projects are defined within the `dependencies` section
 
 ```yaml
 dependencies:
-- name: api-server 
+- name: api-server
   source:
     git: https://github.com/my-api-server
     branch: stable
@@ -114,7 +114,7 @@ dependencies:
   source:
     path: dep1
 dev:
-  # Will open a terminal to the pod with the 
+  # Will open a terminal to the pod with the
   # image from dep1
   terminal:
     imageSelector: ${runtime.dependencies.dep1.images.image1}
@@ -136,7 +136,7 @@ deployments:
 
 ### Referencing Dependencies in Deployment Values / Manifests
 
-It is also possible to reference a dependency's image with [runtime variables](../variables/runtime-variables.mdx) in a deployment:
+It is also possible to reference a dependency's image with [runtime variables](../variables/built-in.mdx) in a deployment:
 ```yaml
 dependencies:
 - name: dep1
@@ -148,7 +148,7 @@ deployments:
       componentChart: true
       values:
         containers:
-          - image: ${runtime.dependencies.dep1.image1.image}:${runtime.dependencies.dep1.image1.tag} # -> replaced with 'myusername/devspace:xxxx' 
+          - image: ${runtime.dependencies.dep1.image1.image}:${runtime.dependencies.dep1.image1.tag} # -> replaced with 'myusername/devspace:xxxx'
 ```
 
 With a dependency `dep1/devspace.yaml` that looks like:

docs/pages/configuration/deployments/helm/basics.mdx

@@ -47,7 +47,7 @@ deployments:
         name: chart-name
         repo: https://my-charts.company.tld/
       values:
-        # If registry.url/repo/image was found under images as well, will be 
+        # If registry.url/repo/image was found under images as well, will be
         # rewritten to registry.url/repo/image:generated_tag
         imageWithTag: registry.url/repo/image
         # If registry.url/repo/image was found under images.app as well, will be
@@ -135,7 +135,7 @@ deployments:
 ```
 
 ### `updateImageTags`
-The `updateImageTags` option expects a boolean stating if DevSpace should do [Image Tag Replacement](../../configuration/deployments/basics.mdx#3-tag-replacement).
+The `updateImageTags` option expects a boolean stating if DevSpace should do [Image Tag Replacement](../basics.mdx#3-tag-replacement).
 
 When set to `true`, DevSpace searches all your values (specified via `values` or `valuesFiles`) for images that are defined in the `images` section of the `devspace.yaml`. If DevSpace finds an image, it replaces or appends the image tag with the tag it created during the image building process. Image tag replacement makes sure that your application will always be started with the most up-to-date image that DevSpace has built for you.
 
@@ -201,7 +201,7 @@ deployments:
       chart:
         name: bitnami/mysql
 ```
-**Explanation:**  
+**Explanation:**
 Deploying the above example would roughly be equivalent to this command:
 ```bash
 helm install database bitnami/mysql
@@ -228,7 +228,7 @@ deployments:
         name: bitnami/mysql
         version: "1.3.1"
 ```
-**Explanation:**  
+**Explanation:**
 Deploying the above example would roughly be equivalent to this command:
 ```bash
 helm install database bitnami/mysql --version="1.3.1"
@@ -246,7 +246,7 @@ deployments:
         name: custom-chart
         repo: https://my-repo.tld/
 ```
-**Explanation:**  
+**Explanation:**
 Deploying the above example would roughly be equivalent to this command:
 ```bash
 helm install database custom-chart --repo "https://my-repo.tld/"
@@ -266,7 +266,7 @@ The `values` option expects an object with values that should be overriding the
 
 Compared to the `valuesFiles` option, using `values` has the following advantages:
 - It is easier to comprehend and faster to find (no references)
-- It allows you to use [dynamic config variables](../../configuration/variables/basics.mdx)
+- It allows you to use [dynamic config variables](../../variables/basics.mdx)
 
 :::info
 Because both, `values` and `valuesFiles`, have advantages and disadvantages, it is often useful to combine them. When setting both, values defined in `values` have precedence over values defined in `valuesFiles`.
@@ -289,7 +289,7 @@ deployments:
         mysqlUser: db_user
         mysqlDatabase: app_database
 ```
-**Explanation:**  
+**Explanation:**
 Deploying the above example would roughly be equivalent to this command:
 ```bash
 helm install database bitnami/mysql --set mysqlRootPassword="$MYSQL_ROOT_PASSWORD" --set mysqlUser="db_user" --set mysqlDatabase="app_database"
@@ -322,7 +322,7 @@ deployments:
       - mysql/values.yaml
       - mysql/values.production.yaml
 ```
-**Explanation:**  
+**Explanation:**
 Deploying the above example would roughly be equivalent to this command:
 ```bash
 helm install database bitnami/mysql -f mysql/values.yaml -f mysql/values.production.yaml
@@ -349,7 +349,7 @@ deployments:
         name: bitnami/mysql
 ```
 
-**Explanation:**  
+**Explanation:**
 Deploying the above example would print the helm output and the `notes.txt` from the bitnami/mysql chart.
 
 ### `templateArgs`

docs/pages/configuration/dev/basics.mdx

@@ -19,7 +19,7 @@ Kubernetes-based development can be useful in the following cases:
 - You want to test your application in a production-like environment
 - You want to debug issues that are hard to reproduce on your local machine
 
-The development experience is very similar to using `docker-compose`, so if you are already familiar on how to develop with `docker-compose`, DevSpace will behave very similar. One of the major benefits of DevSpace versus docker-compose is that DevSpace allows you to develop in any Kubernetes cluster, either locally using minikube, Docker Kubernetes etc. or in any remote Kubernetes cluster.  
+The development experience is very similar to using `docker-compose`, so if you are already familiar on how to develop with `docker-compose`, DevSpace will behave very similar. One of the major benefits of DevSpace versus docker-compose is that DevSpace allows you to develop in any Kubernetes cluster, either locally using minikube, Docker Kubernetes etc. or in any remote Kubernetes cluster.
 
 
 ## Start Development Mode
@@ -93,7 +93,7 @@ DevSpace provides two options to develop applications in Kubernetes:
 :::note Multi-Container Log Streaming (default)
 The first option starts your application as defined in your Dockerfile or in your Kubernetes pod definition. After the pods are started, DevSpace streams the logs of all containers that are started with an image that was built during the image building process. Each log line is prefixed with the image name or alternatively with the pod name of the container. Before starting the actual log streaming, DevSpace prints the last 50 log lines of each container by default.
 
-Learn how to [customize which containers should be included in the log stream and how many log lines should be shown in the beginning](../../configuration/development/log-streaming.mdx).
+Learn how to [customize which containers should be included in the log stream and how many log lines should be shown in the beginning](../../configuration/dev/workflow/log-streaming.mdx).
 :::
 
 :::note Terminal Session
@@ -103,15 +103,15 @@ devspace dev -t
 ```
 Instead of starting the multi-container log streaming, you can also start development mode using a terminal session.
 
-Terminal is configurable by [using the `dev.terminal` configuration section](../../configuration/development/terminal.mdx).
+Terminal is configurable by [using the `dev.terminal` configuration section](../../configuration/dev/workflow/terminal.mdx).
 :::
 
 ### 8. Open Links (optional)
 DevSpace iterates over every item in the `dev.open` array defined in the `devspace.yaml` and tries to open the URL you provide for each item using the following method:
 
 <FragmentWorkflowOpenLinks/>
 
-Learn more about [configuring auto-opening links](../../configuration/development/open-links.mdx).
+Learn more about [configuring auto-opening links](../../configuration/dev/workflow/open.mdx).