Merge branch 'v6-docs-dev' of github.com:jschalz/devspace into v6-docs-dev

Author: jschalz

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

@@ -202,7 +202,7 @@ deployments:
         name: bitnami/mysql
 ```
 **Explanation:**
-Deploying the above example would roughly be equivalent to this command:
+Deploying the above example is roughly equivalent to this command:
 ```bash
 helm install database bitnami/mysql
 ```
@@ -229,7 +229,7 @@ deployments:
         version: "1.3.1"
 ```
 **Explanation:**
-Deploying the above example would roughly be equivalent to this command:
+Deploying the above example is roughly equivalent to this command:
 ```bash
 helm install database bitnami/mysql --version="1.3.1"
 ```
@@ -247,7 +247,7 @@ deployments:
         repo: https://my-repo.tld/
 ```
 **Explanation:**
-Deploying the above example would roughly be equivalent to this command:
+Deploying the above example is roughly equivalent to this command:
 ```bash
 helm install database custom-chart --repo "https://my-repo.tld/"
 ```
@@ -290,7 +290,7 @@ deployments:
         mysqlDatabase: app_database
 ```
 **Explanation:**
-Deploying the above example would roughly be equivalent to this command:
+Deploying the above example is roughly equivalent to this command:
 ```bash
 helm install database bitnami/mysql --set mysqlRootPassword="$MYSQL_ROOT_PASSWORD" --set mysqlUser="db_user" --set mysqlDatabase="app_database"
 ```
@@ -323,7 +323,7 @@ deployments:
       - mysql/values.production.yaml
 ```
 **Explanation:**
-Deploying the above example would roughly be equivalent to this command:
+Deploying the above example is roughly equivalent to this command:
 ```bash
 helm install database bitnami/mysql -f mysql/values.yaml -f mysql/values.production.yaml
 ```
@@ -350,7 +350,7 @@ deployments:
 ```
 
 **Explanation:**
-Deploying the above example would print the helm output and the `notes.txt` from the bitnami/mysql chart.
+Deploying the above example prints the helm output and the `notes.txt` from the bitnami/mysql chart.
 
 ### `templateArgs`
 The `templateArgs` specifies an array of arguments that will be passed by devspace additionally to the standard arguments to `helm template` during `devspace render`.

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`. If you are already familiar on how to develop with `docker-compose`, DevSpace will behave very similar. One of the 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`. If you are already familiar with how to develop with `docker-compose`, DevSpace will behave very similar. One of the 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

docs/pages/configuration/dev/files/sync.mdx

@@ -93,8 +93,8 @@ dev:
 ```
 **Explanation:**
 - Files in `logs/` and in `more/logs/` would not be synchronized at all.
-- Files in `node_modules/` would only be synchronized from the container to the local filesystem but not the other way around.
-- Files in `tmp/` would only be synchroniyed from the local to the container filesystem but not the other way around.
+- Files in `node_modules/` would only be synchronized from the container to the local filesystem, but not the other way around.
+- Files in `tmp/` would only be synchronized from the local to the container filesystem, but not the other way around.
 
 #### Example: Only Sync Specific Folders
 
@@ -388,8 +388,8 @@ The `initialSync` option expects a string with an initial sync strategy. The fol
 
 #### • `mirrorRemote` mirrors the container files to the local filesystem:
 
-1. deletes all files on the local filesystem that are not existing inside the container
-2. downloads all files which are existing inside the container but are missing on the local filesystem
+1. deletes all files on the local filesystem that do not exist inside the container
+2. downloads all files that exist inside the container, but are missing on the local filesystem
 3. resolves all file conflicts (different content on local filesystem than inside the container) by preferring the file within the container (i.e. all files on the local filesystem will be replaced if they are different than inside the container)
 
 #### • `preferRemote` is like `mirrorRemote` but skips step 1.
@@ -434,8 +434,13 @@ dev:
 With this configuration, `devspace dev` performs the following tasks:
 - DevSpace would start port-forwarding and file synchronzation.
 - Initial sync is started automatically.
+<<<<<<< HEAD
 - The first sync config section synchronizes all files except files within `node_modules/`. This means that during initial sync, all remote files that do not already exist locally are deleted, and other files are updated to the most recent version.
 - The second sync config section only synchronizes files within `node_modules/`. Because of `initialSync: preferRemote`, DevSpace downloads all remote files which are not present on the local filesystem and overrides all local files which are different than the files within the container.
+=======
+- The first sync config section would synchronize all files except files within `node_modules/`. This means that during initial sync, all remote files that are not existing locally would be deleted and other files would be updated to the most recent version.
+- The second sync config section only synchronizes files within `node_modules/`. Because of `initialSync: preferRemote`, DevSpace downloads all remote files which are not present on the local filesystem and overrides all local files that are different than the files within the container.
+>>>>>>> 98a495ad09253bb70af2de316c8e06c60e1216d5
 
 ### `waitInitialSync`
 The `waitInitialSync` option expects a boolean which defines if DevSpace should wait until the initial sync process has terminated before opening the container terminal or the multi-container log streaming.
@@ -463,8 +468,13 @@ dev:
       waitInitialSync: false
 ```
 **Explanation:**
+<<<<<<< HEAD
 With the configuration `devspace dev` the following actions will be taken:
 - DevSpace initiates port-forwarding and file synchronization.
+=======
+With the configuration `devspace dev` does the following:
+- DevSpace starts port-forwarding and file synchronization.
+>>>>>>> 98a495ad09253bb70af2de316c8e06c60e1216d5
 - Initial sync would be started automatically.
 
 - Before the initial sync process is finished, DevSpace starts the log streaming.
@@ -542,7 +552,7 @@ Polling might increase CPU consumption of the container drastically, depending o
 :::
 
 :::info
-If you are using a DevSpace config version below `v1beta10`, polling will be enabled by default, as it was the default syncing method in older DevSpace versions
+If you are using a DevSpace config version below `v1beta10`, polling is enabled by default, as it was the default syncing method in older DevSpace versions.
 :::
 
 ## Useful Commands
@@ -584,9 +594,9 @@ The algorithm roughly works like this:
 
 <br/>
 
-The `tar` command has to be present in the container otherwise `kubectl cp` does not work and the helper binary cannot be injected into the container.
+The `tar` command has to be present in the container, otherwise `kubectl cp` will not work and the helper binary cannot be injected into the container.
 
-Other than that, no server-side component or special container privileges for code synchronization are required, as the sync algorithm runs completely client-only within DevSpace. The synchronization mechanism works with any container filesystem and no special binaries have to be installed into the containers. File watchers running within the containers like nodemon will also recognize changes made by the synchronization mechanism.
+No server-side component or special container privileges for code synchronization are required, since the sync algorithm runs completely client-only within DevSpace. The synchronization mechanism works with any container filesystem and no special binaries have to be installed into the containers. File watchers running within the containers like nodemon will also recognize changes made by the synchronization mechanism.
 
 <br/>
 

docs/pages/configuration/images/build-engines/custom.mdx

@@ -21,14 +21,14 @@ images:
     custom:
       skipImageArg: true
       command: |-
-        # Also works on windows as this is executed in a golang shell
+        # Also works on windows, as this is executed in a golang shell
         docker build -t ${runtime.images.backend.image}:${runtime.images.backend.tag} . -f custom/Dockerfile
 ```
 **Explanation:**
 The image `backend` would be built using the command `docker build -t ${runtime.images.backend.image}:${runtime.images.backend.tag} . -f custom/Dockerfile"` while `${runtime.images.backend.image}` would be replaced with the `image` option (in this case: `john/appbackend`) and `${runtime.images.backend.tag}` would be replaced with the tag generated according to the [tagging schema](../../images/image-definition/tags.mdx).
 
 ### `onChange`
-The `onChange` option expects an array of strings which represent paths to files or folders that should be watched for changes. DevSpace uses these paths and the hash values it stores about these paths for evaluating if an image should be rebuilt or if the image building can be skipped because the context of the image has not changed.
+The `onChange` option expects an array of strings which represent paths to files or folders that should be watched for changes. DevSpace uses these paths, and the hash values it stores about these paths, to evaluate if an image should be rebuilt, or if the image building can be skipped because the context of the image has not changed.
 
 :::info
 It is highly recommended to specify this option when using `custom` as build tool in order to speed up the build process.
@@ -52,4 +52,4 @@ images:
       - another/path/file.txt
 ```
 **Explanation:**
-The image `backend` would be built using the command `./build --image "[IMAGE]:[TAG]"` and DevSpace would skip the build if none of the files within `some/path/` nor the file `another/path/file.txt` has changed since the last build.
+The image `backend` is built using the command `./build --image "[IMAGE]:[TAG]"`, and DevSpace skips the build if none of the files within `some/path/`, nor the file `another/path/file.txt`, has changed since the last build.

docs/pages/configuration/images/build-engines/kaniko.mdx

@@ -40,8 +40,8 @@ images:
       cache: false
 ```
 **Explanation:**
-- The first image `backend` would be built using kaniko and make use of the build cache.
-- The second image `frontend` would be built using kaniko and **not** use the build cache.
+- The first image `backend` is built using kaniko and makes use of the build cache.
+- The second image `frontend` is built using kaniko and does **not** use the build cache.
 
 
 ### `snapshotMode`
@@ -71,8 +71,8 @@ images:
       snapshotMode: time
 ```
 **Explanation:**
-- The first image `backend` would be built using kaniko and creating full filesystem snapshots.
-- The second image `frontend` would be built using kaniko and calculate filesystem snapthots only based on `mtime`.
+- The first image `backend` is built using kaniko and creates full filesystem snapshots.
+- The second image `frontend` is built using kaniko and calculates filesystem snapshots only based on `mtime`.
 
 
 ### `insecure`
@@ -96,7 +96,7 @@ images:
       insecure: false
 ```
 **Explanation:**
-The image `backend` would be built using kaniko and pushing to the insecure registry `123.456.789.0:5000` would be allowed.
+The image `backend` is built using kaniko and pushes to the insecure registry `123.456.789.0:5000` if allowed.
 
 
 ### `args`
@@ -122,7 +122,7 @@ images:
       - --verbosity=debug
 ```
 **Explanation:**
-The image `backend` would be built using kaniko and the flags `--cache-dir=/tmp --verbosity=debug` would be set when running the build command within the kaniko pod used for image building.
+The image `backend` is built using kaniko and the flags `--cache-dir=/tmp --verbosity=debug` are set when running the build command within the kaniko pod used for image building.
 
 
 ### `command`
@@ -283,10 +283,10 @@ images:
       pullSecret: custom-pull-secret
 ```
 **Explanation:**
-The image `backend` would be built using kaniko and kaniko would use the Kubernete secret `custom-pull-secret` to pull images from registries that require authentication.
+The image `backend` is built using kaniko. Kaniko uses the Kubernete secret, `custom-pull-secret`, to pull images from registries that require authentication.
 
 :::tip Creating Pull Secrets using `pullSecrets`
-If you use the `pullSecret` option, you have to create the secret before DevSpace tries to build your images. You can automate this by [using the pullSecrets feature](../../pullSecrets/basics.mdx) as shown in this example:
+If you use the `pullSecret` option, you must create the secret before DevSpace tries to build your images. You can automate this by [using the pullSecrets feature](../../pullSecrets/basics.mdx) as shown in this example:
 ```yaml
 pullSecrets:
 - registry: my-registry.com:5000
@@ -349,7 +349,7 @@ images:
             path: token.json
 ```
 **Explanation:**
-The above configuration would create a kaniko container which mounts the following volumes:
+The above configuration creates a kaniko container which mounts the following volumes:
 - All keys within the ConfigMap `my-configmap` will be mounted as files within the folder `/some/configmap/dir`. The filenames will be the keys within the ConfigMap.
 - The key `aws-token` within the Secret `my-secret` will be mounted as the file `/some/secret/dir/token.json`.
 
@@ -396,7 +396,7 @@ images:
       namespace: build-namespace
 ```
 **Explanation:**
-The image `backend` would be built using kaniko and the build pod started to run the kaniko build process would be created within the namespace `build-namespace` within the cluster that the current kube-context points to.
+The image `backend` is built using kaniko. The build pod starts to run the kaniko build process and creates the namespace `build-namespace` within the cluster that the current kube-context points to.
 
 ### `serviceAccount`
 

docs/pages/configuration/images/build-settings/network.mdx

@@ -15,4 +15,4 @@ images:
     network: host
 ```
 **Explanation:**
-The image `backend` would be built using `docker` and `docker build` would be called using the `--network=host` flag.
+The image `backend` is built using `docker`, and `docker build` is called using the `--network=host` flag.

docs/pages/configuration/images/image-definition/dockerfile.mdx

@@ -27,9 +27,9 @@ images:
     context: frontend/
 ```
 **Explanation:**
-- The first image would be built using the Dockerfile in `./Dockerfile` and the context path `./`.
-- The second image would be built using the Dockerfile in `./frontend/Dockerfile` and the context path `./frontend/`.
-- Switching the `context` for image `frontend` would assure that a statement like `ADD file.txt` or  `COPY file.txt .` in `./frontend/Dockerfile` would use the local file `./frontend/file.txt` instead of `./file.txt`.
+- The first image is built using the Dockerfile in `./Dockerfile` and the context path `./`.
+- The second image is built using the Dockerfile in `./frontend/Dockerfile` and the context path `./frontend/`.
+- Switching the `context` for image `frontend` assures that a statement like `ADD file.txt` or  `COPY file.txt .` in `./frontend/Dockerfile` uses the local file `./frontend/file.txt` instead of `./file.txt`.
 - In this example, it would probably be useful to have a `./.dockerignore` file which ignores the `frontend/` folder when building the first image called `backend`.
 
 :::note

docs/pages/configuration/images/image-definition/tags.mdx

@@ -20,7 +20,7 @@ images:
 ```
 
 :::info Unique Tags For Development
-**Make sure tags are unique** when defining a custom tagging schema for development. Unique tags ensure that your application gets started with the newly built image instead of using an older, cached version. Therefore, it is highly recommended for non-production tags to either use `#` placeholders or `devspace.timestamp` as a suffix in your tagging schema (see [example below](#example-custom-tagging-schema)).
+**Make sure tags are unique** when defining a custom tagging schema for development. Unique tags ensure your application starts with the newly built image instead of using an older, cached version. Therefore, it is highly recommended for non-production tags to either use `#` placeholders or `devspace.timestamp` as a suffix in your tagging schema (see [example below](#example-custom-tagging-schema)).
 :::
 
 #### Default Value For `tag`
@@ -39,7 +39,7 @@ images:
     - dev-backend-${devspace.git.commit}-#####
 ```
 **Explanation:**
-The above example would always use the tag `latest` and additionaly generate random tags which could look like this one: `dev-backend-b6caf8a-Jak9i`. This example tag consists of the following substrings defined by the tagging schema:
+The above example always uses the tag `latest`, while generating random tags which could look like this one: `dev-backend-b6caf8a-Jak9i`. This example tag consists of the following substrings defined by the tagging schema:
 - `dev-` static string
 - `-backend-` static string
 - `b6caf8a` latest git commit hash on current local branch

docs/pages/guides/ci-cd-integration.mdx

@@ -44,7 +44,7 @@ DevSpace is configured to deploy and terminate when you run `devspace deploy`. I
 ```bash
 devspace deploy --wait --timeout=120
 ```
-The above command will wait until the desired number of pods is created for all ReplicaSets and until none of the pods are failing anymore. If this is not achieved within the number of seconds specified in `--timeout`, DevSpace will exit with a fatal error.
+The above command will wait until the desired number of pods is created for all ReplicaSets, and until none of the pods are failing. If this is not achieved within the number of seconds specified in `--timeout`, DevSpace will exit with a fatal error.
 
 ### Separate Build & Deploy
 DevSpace allows you to split up the build and deployment process into two separate commands: