diff --git a/README.md b/README.md
index 99b7e607e0..986285f9a1 100644
--- a/README.md
+++ b/README.md
@@ -87,7 +87,7 @@ Instead of rebuilding images and redeploying containers, DevSpace allows you to
Deploying and debugging services with Kubernetes requires a lot of knowledge and forces you to repeatedly run commands like `kubectl get pod` and copy pod ids back and forth. Stop wasting time and let DevSpace automate the tedious parts of working with Kubernetes:
-- DevSpace lets you build multiple images in parallel, tag them automatically and and deploy your entire application (including its dependencies) with just a single command
+- DevSpace lets you build multiple images in parallel, tag them automatically and deploy your entire application (including its dependencies) with just a single command
- Let DevSpace automatically start port-fowarding and log streaming, so you don't have to constantly copy and paste pod ids or run 10 commands to get everything started.
diff --git a/cmd/init.go b/cmd/init.go
index b9874cbd6e..0ee45d437f 100644
--- a/cmd/init.go
+++ b/cmd/init.go
@@ -96,7 +96,7 @@ folder. Creates a devspace.yaml as a starting point.
}
initCmd.Flags().BoolVarP(&cmd.Reconfigure, "reconfigure", "r", false, "Change existing configuration")
- initCmd.Flags().StringVar(&cmd.Context, "context", "", "Context path to use for intialization")
+ initCmd.Flags().StringVar(&cmd.Context, "context", "", "Context path to use for initialization")
initCmd.Flags().StringVar(&cmd.Dockerfile, "dockerfile", helper.DefaultDockerfilePath, "Dockerfile to use for initialization")
initCmd.Flags().StringVar(&cmd.Provider, "provider", "", "The cloud provider to use")
@@ -508,7 +508,7 @@ echo 'Anyone using this project can invoke it via "devspace run migrate-db"'`,
config.Pipelines["dev"] = &latest.Pipeline{
Run: `run_dependencies --all # 1. Deploy any projects this project needs (see "dependencies")
ensure_pull_secrets --all # 2. Ensure pull secrets
-create_deployments --all # 3. Deploy Helm charts and manifests specfied as "deployments"
+create_deployments --all # 3. Deploy Helm charts and manifests specified as "deployments"
start_dev ` + imageName + ` # 4. Start dev mode "` + imageName + `" (see "dev" section)`,
}
@@ -517,7 +517,7 @@ start_dev ` + imageName + ` # 4. Start dev mode "` + imageName +
Run: `run_dependencies --all # 1. Deploy any projects this project needs (see "dependencies")
ensure_pull_secrets --all # 2. Ensure pull secrets
build_images --all -t $(git describe --always) # 3. Build, tag (git commit hash) and push all images (see "images")
-create_deployments --all # 4. Deploy Helm charts and manifests specfied as "deployments"`,
+create_deployments --all # 4. Deploy Helm charts and manifests specified as "deployments"`,
}
// Save config
diff --git a/cmd/logs.go b/cmd/logs.go
index 1304baa89d..30e163bf4c 100644
--- a/cmd/logs.go
+++ b/cmd/logs.go
@@ -50,7 +50,7 @@ func NewLogsCmd(f factory.Factory, globalFlags *flags.GlobalFlags) *cobra.Comman
#######################################################
#################### devspace logs ####################
#######################################################
-Prints the last log of a pod container and attachs
+Prints the last log of a pod container and attaches
to it
Example:
diff --git a/docs/pages/_partials/config-dependencies.mdx b/docs/pages/_partials/config-dependencies.mdx
index 64ab12909d..721dda0d12 100644
--- a/docs/pages/_partials/config-dependencies.mdx
+++ b/docs/pages/_partials/config-dependencies.mdx
@@ -18,7 +18,7 @@ dependencies: # struct[] | Array of dependencies (other p
ports: false # bool | Reuse dev.ports config from the dependency
sync: false # bool | Reuse dev.sync config from the dependency
overwriteVars: true # bool | If not defined or true, will overwrite values of variables with the same name in the dependency
- vars: # struct[] | Variables in the dependency config that should be overriden with the specified values
+ vars: # struct[] | Variables in the dependency config that should be overridden with the specified values
- name: NAME
value: value
disableProfileActivation: true # bool | If true will ignore profile activations for this dependency
diff --git a/docs/pages/_partials/dependency-vars.mdx b/docs/pages/_partials/dependency-vars.mdx
index 9348f9e66e..5c8d1ea4f2 100644
--- a/docs/pages/_partials/dependency-vars.mdx
+++ b/docs/pages/_partials/dependency-vars.mdx
@@ -1,4 +1,4 @@
-The `vars` option expects an array of objects with name and value of variables defined in the `devspace.yaml` of this dependency. When configuring this option, the variables will be overriden similar to passing variables via the `--var` flag to devspace.
+The `vars` option expects an array of objects with name and value of variables defined in the `devspace.yaml` of this dependency. When configuring this option, the variables will be overridden similar to passing variables via the `--var` flag to devspace.
It is also useful to deploy the same dependency multiple times with just small adjustments.
#### Example: Override Config Vars for Dependency
diff --git a/docs/pages/_partials/workflow-open-links.mdx b/docs/pages/_partials/workflow-open-links.mdx
index 94f9790451..64406b560d 100644
--- a/docs/pages/_partials/workflow-open-links.mdx
+++ b/docs/pages/_partials/workflow-open-links.mdx
@@ -1,4 +1,4 @@
-1. DevSpace starts to periodically send `HTTP GET` requests to the URLs provideded via `dev.*.open[*].url`.
+1. DevSpace starts to periodically send `HTTP GET` requests to the URLs provided via `dev.*.open[*].url`.
2. As soon as the first HTTP response has a status code which is neither 502 (Bad Gateway) nor 503 (Service Unavailable), DevSpace assumes that the application is now started, stops sending any further requests and opens the provided URL in the browser.
3. If the URL is still returning status code 502 or 503 after 4min, DevSpace will stop trying to open it. To not disturb the log streaming or the interactive terminal session, DevSpace will not show an error when hitting the 4min timeout.
diff --git a/docs/pages/cli/devspace_init.md b/docs/pages/cli/devspace_init.md
index 4532077ade..6f7ec9ad67 100644
--- a/docs/pages/cli/devspace_init.md
+++ b/docs/pages/cli/devspace_init.md
@@ -26,7 +26,7 @@ folder. Creates a devspace.yaml as a starting point.
## Flags
```
- --context string Context path to use for intialization
+ --context string Context path to use for initialization
--dockerfile string Dockerfile to use for initialization (default "./Dockerfile")
-h, --help help for init
--provider string The cloud provider to use
diff --git a/docs/pages/cli/devspace_logs.md b/docs/pages/cli/devspace_logs.md
index b211ba04ce..12873f2942 100644
--- a/docs/pages/cli/devspace_logs.md
+++ b/docs/pages/cli/devspace_logs.md
@@ -17,7 +17,7 @@ devspace logs [flags]
#######################################################
#################### devspace logs ####################
#######################################################
-Prints the last log of a pod container and attachs
+Prints the last log of a pod container and attaches
to it
Example:
diff --git a/docs/pages/configuration/dev/connections/file-sync.mdx b/docs/pages/configuration/dev/connections/file-sync.mdx
index 348e8994d3..a41fafeab4 100644
--- a/docs/pages/configuration/dev/connections/file-sync.mdx
+++ b/docs/pages/configuration/dev/connections/file-sync.mdx
@@ -270,7 +270,7 @@ dev:
The `initialSync` option expects a string with an initial sync strategy. The following strategies are available:
`mirrorLocal` mirrors the local filesystem inside the container (default)
- 1. deletes all files inside the conainer that are not existing on the local filesystem
+ 1. deletes all files inside the container that are not existing on the local filesystem
2. uploads all files which are existing on the local filesystem but are missing within the container
3. resolves all file conflicts (different content on local filesystem than in inside the container) by preferring the file on the local filesystem (i.e. all files in the container will be replaced if they are different from on the local filesystem)
@@ -438,7 +438,7 @@ DevSpace establishes a bi-directional code synchronization between the specified
The algorithm roughly works like this:
1. Inject a small helper binary via `kubectl cp` into the target container
-2. Run initial sync accoring to the [`initialSync` config option](#initial-sync)
+2. Run initial sync according to the [`initialSync` config option](#initial-sync)
3. Watch for file changes on both sides (local and remote) and sync them according to the [sync path mappings](#sync-path-mapping)
4. After every sync process, [restart the container](#onuploadrestartcontainer) or run other custom [post-sync commands](#post-sync-commands) (optional)
diff --git a/docs/pages/configuration/dev/connections/terminal.mdx b/docs/pages/configuration/dev/connections/terminal.mdx
index c568da3a5e..eb303107d9 100644
--- a/docs/pages/configuration/dev/connections/terminal.mdx
+++ b/docs/pages/configuration/dev/connections/terminal.mdx
@@ -100,7 +100,7 @@ dev:
lastLines: 100
```
-DevSpace will continously check what pods match the given selectors and start or end log streaming accordingly.
+DevSpace will continuously check what pods match the given selectors and start or end log streaming accordingly.
## Config Reference
diff --git a/docs/pages/configuration/hooks/README.mdx b/docs/pages/configuration/hooks/README.mdx
index 97c249936d..f01f2b29d6 100644
--- a/docs/pages/configuration/hooks/README.mdx
+++ b/docs/pages/configuration/hooks/README.mdx
@@ -55,7 +55,7 @@ If any hook returns a non-zero exit code, DevSpace will abort and print an error
For `error:` events the actual error will be passed to the hook via the environment variable `DEVSPACE_HOOK_ERROR`. For example:
```yaml
-# This will print the error to the console that has occured during a deployment
+# This will print the error to the console that has occurred during a deployment
hooks:
- events: ["error:deploy:*"]
command: "echo The following error has occurred during deploying $DEVSPACE_HOOK_DEPLOY_NAME: $DEVSPACE_HOOK_ERROR"
@@ -272,7 +272,7 @@ DevSpace passes certain environment variables to the hook execution:
- **DEVSPACE_HOOK_KUBE_CONTEXT**: the name of the kube context that was used
- **DEVSPACE_HOOK_KUBE_NAMESPACE**: the name of the kube namespace that was used
- **DEVSPACE_HOOK_OS_ARGS**: json encoded os.Args that were used to call devspace
-- **DEVSPACE_HOOK_ERROR**: if an error has occured contains the error string (only for onError hooks)
+- **DEVSPACE_HOOK_ERROR**: if an error has occurred contains the error string (only for onError hooks)
- **DEVSPACE_HOOK_EVENT**: the event that has triggered the hook
Depending on the hook there will be other context variables set that are prefixed with `DEVSPACE_HOOK_`.
diff --git a/docs/pages/configuration/images/build-engines/buildkit.mdx b/docs/pages/configuration/images/build-engines/buildkit.mdx
index 8a85758fe1..a33dd3e2ee 100644
--- a/docs/pages/configuration/images/build-engines/buildkit.mdx
+++ b/docs/pages/configuration/images/build-engines/buildkit.mdx
@@ -67,7 +67,7 @@ If in-cluster building is not explicitly enabled, DevSpace checks if a local Doc
DevSpace preferably uses the Docker daemon running in the virtual machine that belongs to your local Kubernetes cluster instead of your regular Docker daemon. This has the advantage that images do not need to be pushed to a registry because Kubernetes can simply use the images available in the Docker daemon belonging to the kubelet of the local cluster. Using this method is only possible when your current kube-context points to a local Kubernetes cluster and is named `minikube`, `docker-desktop` or `docker-for-desktop`.
-### In-Cluster Deamon
+### In-Cluster Daemon
If the `inCluster` field is defined for an image, DevSpace will build the image directly in the Kubernetes cluster instead of using the local Docker daemon. DevSpace will start or reuse a BuildKit deployment in the Kubernetes cluster that acts as target BuildKit daemon. For example:
```yaml
images:
diff --git a/docs/pages/configuration/images/build-engines/kaniko.mdx b/docs/pages/configuration/images/build-engines/kaniko.mdx
index d55c5fb0fb..addc7ea6b3 100644
--- a/docs/pages/configuration/images/build-engines/kaniko.mdx
+++ b/docs/pages/configuration/images/build-engines/kaniko.mdx
@@ -303,7 +303,7 @@ images:
pullSecret: custom-pull-secret
```
**Explanation:**
-The image `backend` is built using kaniko. Kaniko uses the Kubernete secret, `custom-pull-secret`, to pull images from registries that require authentication.
+The image `backend` is built using kaniko. Kaniko uses the Kubernetes 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 must create the secret before DevSpace tries to build your images. You can automate this by [using the pullSecrets feature](../../pullSecrets/README.mdx) as shown in this example:
diff --git a/docs/pages/configuration/images/build.mdx b/docs/pages/configuration/images/build.mdx
index f05dd2918b..fca2860b38 100644
--- a/docs/pages/configuration/images/build.mdx
+++ b/docs/pages/configuration/images/build.mdx
@@ -196,7 +196,7 @@ DevSpace provides several config options to make in-memory changes to the build
By default, DevSpace tries to skip building images as much as possible. Once any of your images is built once, DevSpace will only rebuild it if one of the conditions is true:
- The `dockerfile` has changed
- Any file within the build `context` folder has changed (while respecting `.dockerignore` rules)
-- The image configuration within the `devspace.yaml` has changed (including values set in the pipeline scripe, e.g. via `--set`)
+- The image configuration within the `devspace.yaml` has changed (including values set in the pipeline script, e.g. via `--set`)
- The image was **not** been built before or the `.devspace/` folder has been deleted/manipulated
You can explicitly override this behavior using the `rebuildStrategy` field:
diff --git a/docs/pages/configuration/images/push.mdx b/docs/pages/configuration/images/push.mdx
index 5f78a1f023..9e5c27ed34 100644
--- a/docs/pages/configuration/images/push.mdx
+++ b/docs/pages/configuration/images/push.mdx
@@ -61,7 +61,7 @@ The local registry is used as a fallback by default. DevSpace will try to push i
- Use `kind load docker-image` if using a local [KinD](https://kind.sigs.k8s.io/) cluster
- Deploy and use local registry
-The local registry can be explicity enabled or disabled to change the default behavior. Changing `enabled` to `true` will force using the local registry instead of `kind load docker-image`
+The local registry can be explicitly enabled or disabled to change the default behavior. Changing `enabled` to `true` will force using the local registry instead of `kind load docker-image`
```yaml title=devspace.yaml
version: v2beta1
localRegistry:
diff --git a/docs/pages/configuration/pipelines/README.mdx b/docs/pages/configuration/pipelines/README.mdx
index 644ddb1db0..f5654b8738 100644
--- a/docs/pages/configuration/pipelines/README.mdx
+++ b/docs/pages/configuration/pipelines/README.mdx
@@ -172,7 +172,7 @@ pipelines:
type: string
run: |-
if ! is_empty $(get_flag dockerfile); then
- echo "Building the image with the overriden dockerfile $(get_flag dockerfile)"
+ echo "Building the image with the overridden dockerfile $(get_flag dockerfile)"
run_default_pipeline deploy --set "images.my-image.dockerfile=$(get_flag dockerfile)"
else
run_default_pipeline deploy
@@ -197,12 +197,12 @@ pipelines:
# Override the default pipeline for 'devspace dev'
dev: |-
run_dependency_pipelines --all # 1. Deploy any projects this project needs (see "dependencies")
- create_deployments --all # 2. Deploy Helm charts and manifests specfied as "deployments"
+ create_deployments --all # 2. Deploy Helm charts and manifests specified as "deployments"
start_dev app # 3. Start dev mode "app" (see "dev" section)
deploy: |-
run_dependency_pipelines --all # 1. Deploy any projects this project needs (see "dependencies")
build_images --all -t $(git describe --always) # 2. Build, tag (git commit hash) and push all images (see "images")
- create_deployments --all # 3. Deploy Helm charts and manifests specfied as "deployments"
+ create_deployments --all # 3. Deploy Helm charts and manifests specified as "deployments"
build:
# Here we are using the long-form using `run:` instead of passing the script directly
run: |-
@@ -224,12 +224,12 @@ devspace run-pipeline [name]
```
:::info Cross-Platform Execution
-Write all pipeline scrips in `bash` fashion. DevSpace is using a library to make them cross-platform executable.
+Write all pipeline scripts in `bash` fashion. DevSpace is using a library to make them cross-platform executable.
:::
## Default Pipelines
-Internally DevSpace uses pipelines for the following commands that can be overriden according to your preferences. DevSpace provides default pipeline scripts for the following top-level commands:
+Internally DevSpace uses pipelines for the following commands that can be overridden according to your preferences. DevSpace provides default pipeline scripts for the following top-level commands:
- [`devspace dev`](#dev)
- [`devspace deploy`](#deploy)
- [`devspace build`](#build)
diff --git a/docs/pages/configuration/profiles/README.mdx b/docs/pages/configuration/profiles/README.mdx
index 73570bec82..0a7d81effe 100644
--- a/docs/pages/configuration/profiles/README.mdx
+++ b/docs/pages/configuration/profiles/README.mdx
@@ -71,7 +71,7 @@ devspace list profiles
```
### `devspace [deploy] -p [profile]`
-Most DevSpace commands support the `-p / --profile` flag. Using this flag, you can run a single command with a different profile without switching your profile permenantly:
+Most DevSpace commands support the `-p / --profile` flag. Using this flag, you can run a single command with a different profile without switching your profile permanently:
```bash
devspace build -p [PROFILE_NAME]
devspace deploy -p [PROFILE_NAME]
diff --git a/docs/pages/configuration/profiles/activation.mdx b/docs/pages/configuration/profiles/activation.mdx
index 7f0ad69e69..051a3af50b 100644
--- a/docs/pages/configuration/profiles/activation.mdx
+++ b/docs/pages/configuration/profiles/activation.mdx
@@ -110,4 +110,4 @@ dependencies:
```
### Disable Activations Globally
-The `--disable-profile-activation` flag can be used to disable all profile activations, including those specifed within each dependency's `devspace.yaml`.
+The `--disable-profile-activation` flag can be used to disable all profile activations, including those specified within each dependency's `devspace.yaml`.
diff --git a/docs/pages/configuration/variables.mdx b/docs/pages/configuration/variables.mdx
index 12b6e887cd..5974c037dc 100644
--- a/docs/pages/configuration/variables.mdx
+++ b/docs/pages/configuration/variables.mdx
@@ -31,7 +31,7 @@ DevSpace provides a set of built-in variables:
- `${DEVSPACE_VERSION}` contains the version of DevSpace that is currently running
## Custom Variables
-DevSpace lets you define custom varables inside `devspace.yaml` within the `vars` section.
+DevSpace lets you define custom variables inside `devspace.yaml` within the `vars` section.
:::tip Mix & Match Variable Types
You can define several types of variables in the same config file, e.g. one `devspace.yaml` can contain static variables, env variables and more.
diff --git a/docs/pages/getting-started/development.mdx b/docs/pages/getting-started/development.mdx
index fd51784ddf..d467abecfb 100644
--- a/docs/pages/getting-started/development.mdx
+++ b/docs/pages/getting-started/development.mdx
@@ -35,7 +35,7 @@ pipelines:
dev:
run: |-
run_dependencies --all # 1. Deploy any projects this project needs (see "dependencies")
- create_deployments --all # 2. Deploy Helm charts and manifests specfied as "deployments"
+ create_deployments --all # 2. Deploy Helm charts and manifests specified as "deployments"
start_dev app # 3. Start dev mode "app" (see "dev" section)
```
diff --git a/docs/pages/getting-started/initialize-project.mdx b/docs/pages/getting-started/initialize-project.mdx
index 6ab0892827..6548057cc0 100644
--- a/docs/pages/getting-started/initialize-project.mdx
+++ b/docs/pages/getting-started/initialize-project.mdx
@@ -98,7 +98,7 @@ You can now run:
Run `devspace -h` or `devspace [command] -h` to see a list of available commands and flags
```
-Congratulations! You have succesfully initialized your first DevSpace project! 🎉
+Congratulations! You have successfully initialized your first DevSpace project! 🎉
After running `devspace init`, you will see 3 changes in your project:
1. New file `devspace.yaml` (tells DevSpace how this project should be build, deployed, and developed)
@@ -116,14 +116,14 @@ pipelines:
dev:
run: |-
run_dependencies --all # 1. Deploy any projects this project needs (see "dependencies")
- create_deployments --all # 2. Deploy Helm charts and manifests specfied as "deployments"
+ create_deployments --all # 2. Deploy Helm charts and manifests specified as "deployments"
start_dev app # 3. Start dev mode "app" (see "dev" section)
# You can run this pipeline via `devspace deploy` (or `devspace run-pipeline deploy`)
deploy:
run: |-
run_dependencies --all # 1. Deploy any projects this project needs (see "dependencies")
build_images --all -t $(git describe --always) # 2. Build, tag (git commit hash) and push all images (see "images")
- create_deployments --all # 3. Deploy Helm charts and manifests specfied as "deployments"
+ create_deployments --all # 3. Deploy Helm charts and manifests specified as "deployments"
# This is a list of `images` that DevSpace can build for this project
# We recommend to skip image building during development (devspace dev) as much as possible