Merge pull request loft-sh#773 from syedzubeen/main

Minor doc fixes/enhancements

docs/pages/developing-in-workspaces/devcontainer-json.mdx

@@ -9,7 +9,7 @@ Within DevPod, this container is created based on the underlying provider either
 DevPod makes sure that no matter where you use this configuration the developer experience stays the same.
 
 You can configure this development container for a certain git repository so that each workspace gives you a custom development environment
-completely configured with tooling and runtimes you need for working on that specific project.
+completely configured with the tooling and runtimes you need for working on that specific project.
 If DevPod doesn't find any configuration for the project it will automatically detect the programming language and provide a sane default configuration.
 
 :::info Compatibility with VS Code & Codespaces
@@ -25,7 +25,7 @@ This page mostly gives you an introduction on how to work with devcontainers. Fo
 :::
 
 :::warning Unsupported Properties
-Currently these `devcontainer.json` properties are not supported in DevPod. These may be implemented in future releases.
+Currently, these `devcontainer.json` properties are not supported in DevPod. These may be implemented in future releases.
 * userEnvProve
 * waitFor
 * Parallel lifecycle scripts
@@ -35,7 +35,7 @@ Currently these `devcontainer.json` properties are not supported in DevPod. Thes
 
 The primary file to configure your workspace is the `devcontainer.json`, that lives in the `.devcontainer` sub-folder of your project.
 This file includes information on what frameworks, tools, VS Code extensions and port-forwarding should be used during development.
-The file also usually references a Dockerfile or an Docker image to use as the base for the development environment.
+The file also usually references a Dockerfile or a Docker image to use as the base for the development environment.
 If DevPod doesn't find any configuration for the project, it will automatically detect the programming language and provide a sane default configuration.
 
 The `devcontainer.json` can be located at the following places within your project:
@@ -81,7 +81,7 @@ A list of available features can be found [here](https://containers.dev/features
 
 Devpod is able to add HTTP headers when downloading
 feature archives as tar.gz files. To do so, add the needed headers in the `customizations`
-field of the `devcontainer.json` file as follow:
+field of the `devcontainer.json` file as follows:
 
 ```
 {
@@ -105,7 +105,7 @@ field of the `devcontainer.json` file as follow:
 When working on the `devcontainer.json` itself, it's important to understand when DevPod will apply new configuration.
 
 A naive approach would be to delete and recreate a workspace after each `devcontainer.json` change (which obviously works), but DevPod allows you to make changes to the configuration on the fly and reapply them via `devpod up my-workspace --recreate`.
-This will apply **ALL** new configuration including Dockerfile changes as well as new mounts, new features or any other configuration that is not included in the above command. DevPod will only replace the existing running container if the command has succeeded, so if there is a mistake in the new configuration, the existing workspace should not be impacted.
+This will apply **ALL** new configurations including Dockerfile changes as well as new mounts, new features or any other configuration that is not included in the above command. DevPod will only replace the existing running container if the command has succeeded, so if there is a mistake in the new configuration, the existing workspace should not be impacted.
 The Desktop app equivalent for this is the 'Rebuild' button.
 
 :::warning Recreating / Rebuilding

docs/pages/developing-in-workspaces/environment-variables-in-devcontainer-json.mdx

@@ -3,7 +3,7 @@ title: Environment variables in devcontainer.json
 sidebar_label: Environment variables in devcontainer.json
 ---
 
-If you're combining ssh provider with using environment variables in your `.devcontainer.json`,
+If you're combining SSH provider with using environment variables in your `.devcontainer.json`,
 please follow the steps below to make sure that your environment variables are properly set on the remote machine.
 
 ### Steps
@@ -30,7 +30,7 @@ Host <REMOTE-SSH-SERVER>
 AcceptEnv IMAGE_VERSION
 ```
 
-4. Restart ssh service on your remote machine.<br/>
+4. Restart SSH service on your remote machine.<br/>
 For example on Debian Linux:
 ```console
 systemctl restart ssh.service

docs/pages/developing-in-workspaces/what-are-workspaces.mdx

@@ -9,6 +9,6 @@ The underlying environment where the container runs will be created and managed
 To configure the development container, DevPod reuses the [devcontainer.json](https://containers.dev/) specification, which is also used by other popular tools, such as [VS Code dev containers](https://code.visualstudio.com/docs/devcontainers/containers) or [Github Codespaces](https://github.com/features/codespaces).
 This means you can already reuse projects that use this configuration to spin up a workspace in DevPod. If no configuration is found, DevPod will automatically try to find out what programming language is used and provide an appropriate template.
 
-A workspace in DevPod can be stopped and restarted without losing its state. This allows you to install additional programs or change configuration without the need of reconfiguring the container.
+A workspace in DevPod can be stopped and restarted without losing its state. This allows you to install additional programs or change configuration without the need to reconfigure the container.
 Depending on the Provider, DevPod will also automatically determine when a workspace is currently not be used and shutdown any unused resources to save costs.
 

docs/pages/developing-providers/agent.mdx

@@ -3,7 +3,7 @@ title: Provider Agent
 sidebar_label: Provider Agent
 ---
 
-When DevPod connects through a Provider to an environment, it will inject itself into the environment to handle the following tasks there:
+When DevPod connects through a Provider to an environment, it will inject itself into the environment to handle the following tasks:
 - deploying the container
 - forward credentials
 - ssh server
@@ -25,7 +25,7 @@ the provider
 The following options are available in the `agent` section
 
 ```yaml
-agent: # You can also use options within this section (see injectGitCredentials as example)
+agent: # You can also use options within this section (see injectGitCredentials as an example)
   path: ${DEVPOD}
   driver: docker # Optional, default: docker
   inactivityTimeout: 10m
@@ -55,7 +55,7 @@ Breaking down the options:
 - **binaries**: this section can be used to declare additional binaries to download on the machine to use in `exec.shutdown`
 
 :::info
-The `binaries` section is useful to inject a helper binary in the machine, in order to
+The `binaries` section is useful for injecting a helper binary in the machine, in order to
 use the specific cloud's APIs to shut down the machine, if a simple `shutdown -h now` does not work
 :::
 
@@ -85,4 +85,4 @@ Official providers that use this method of automatically stopping an inactive ma
 - [devpod-provider-azure](https://github.com/loft-sh/devpod-provider-azure): Just uses `shutdown -t now` as `agent.exec.shutdown` to shutdown an unused machine.
 - [devpod-provider-aws](https://github.com/loft-sh/devpod-provider-aws): Uses the local `aws` cli tool to generate a temporary token, which is then saved in a DevPod option. This token is then used within `agent.exec.shutdown` to shutdown the machine on the agent side with an AWS api call.
 - [devpod-provider-gcloud](https://github.com/loft-sh/devpod-provider-gcloud): Uses the local `gcloud` cli tool to generate a temporary token, which is then saved in a DevPod option. This token is then used within `agent.exec.shutdown` to shutdown the machine on the agent side with an Google Cloud api call.
-- [devpod-provider-digitalocean](https://github.com/loft-sh/devpod-provider-digitalocean): Deletes the whole machine on inactivity as stopped machines are still billed by DigitalOcean. The local digital ocean token is reused on the agent side to make a API call to delete the whole machine and preserve state in an extra volume.
+- [devpod-provider-digitalocean](https://github.com/loft-sh/devpod-provider-digitalocean): Deletes the whole machine on inactivity as stopped machines are still billed by DigitalOcean. The local digital ocean token is reused on the agent side to make an API call to delete the whole machine and preserve the state in an extra volume.

docs/pages/developing-providers/driver.mdx

@@ -7,7 +7,7 @@ In DevPod you can specify a **Driver** in the [Agent's configuration](./agent.md
 
 A Driver indicates how DevPod deploys the workspace container.
 
-There are two type of drivers:
+There are two types of drivers:
 
 - Docker driver
 - Kubernetes driver
@@ -18,7 +18,7 @@ If no driver is specified, the default is **Docker**
 
 ## Docker Driver
 
-Docker driver is the default driver that DevPod uses to deploy the workspace container.
+The Docker driver is the default driver that DevPod uses to deploy the workspace container.
 
 This container (specified through a [devcontainer.json](../developing-in-workspaces/devcontainer-json.mdx)),
 is executed through Docker inside the provider environment, for example in a VM [in case of Machine Providers](../managing-providers/what-are-providers.mdx).
@@ -41,11 +41,11 @@ agent:
 ## Kubernetes Driver
 
 Instead of Docker, DevPod is also able to use Kubernetes as a Driver, which allows you to deploy the workspace to a Kubernetes cluster instead.
-For example, this makes it possible to create a provider that spins up a remote Kubernetes cluster (or just namespace), connect to it and create a workspace there.
+For example, this makes it possible to create a provider that spins up a remote Kubernetes cluster (or just a namespace), connect to it, and create a workspace there.
 DevPod also has a default Kubernetes provider that uses the local Kubernetes config file to deploy the workspace.
 
 DevPod also allows building an image through Kubernetes with [buildkit](https://github.com/moby/buildkit).
-DevPod will automatically determine if building is necessary or a prebuild can be used. However, the `buildRepository` option needs to be specified for this to work.
+DevPod will automatically determine if building is necessary or if a prebuild can be used. However, the `buildRepository` option needs to be specified for this to work.
 
 The allowed options for the Kubernetes driver are:
 - **path**: where to find the `kubectl` binary or a drop-in replacement

docs/pages/developing-providers/options.mdx

@@ -64,10 +64,10 @@ configuring or adding the provider:
 - `required`: Boolean if this option needs to be non-empty before using the provider. DevPod will ask in the CLI and make sure that this option is filled in the Desktop application.
 - `password`: Boolean to indicate this is a sensitive value. Prevents this value from showing up in the `devpod provider options` command and will be a password field in the Desktop application.
 - `suggestions`: An array of suggestions for this option. Will be shown as auto complete options in the DevPod desktop application
-- `command`: A command to retrieve the option value automatically. Can also reference other variables in the command, e.g. `echo ${MY_OTHER_VAR}-suffix`. For compatibility reasons this command will be executed in an emulated shell on windows.
+- `command`: A command to retrieve the option value automatically. Can also reference other variables in the command, e.g. `echo ${MY_OTHER_VAR}-suffix`. For compatibility reasons, this command will be executed in an emulated shell on Windows.
 - `local`: If true, the option will be filled individually for each machine / workspace
 - `global`: If true, the option will be reused for each machine / workspace
-- `cache`: If non-empty, DevPod will reexecute the command after the given timeout. E.g. if this is 5m, DevPod will reexecute the command after 5 minutes to re-fill this value. This is useful if you want to store a token or something that expires locally in a variable.
+- `cache`: If non-empty, DevPod will re-execute the command after the given timeout. E.g. if this is 5m, DevPod will re-execute the command after 5 minutes to re-fill this value. This is useful if you want to store a token or something that expires locally in a variable.
 - `hidden`: If true, DevPod will not show this option in the Desktop application or through `devpod provider options`. Can be used to calculate variables internally or save tokens or other things internally.
 
 ### Default values
@@ -77,7 +77,7 @@ to place a sensible default for any option.
 
 You can also reference other options inside the default value, e.g. `${MY_OTHER_VAR}-suffix`. DevPod will automatically figure out what options need to be resolved before this option.
 
-**If not specified, it defaults to empty string**.
+**If not specified, it defaults to an empty string**.
 
 ### Required options
 
@@ -126,7 +126,7 @@ be shown in the CLI app.
 ### Command options
 
 The command option lets you define a possible value for an option based on a shell
-command launched on your machine. Can also reference other variables in the command, e.g. `echo ${MY_OTHER_VAR}-suffix`. For compatibility reasons this command will be executed in an emulated shell on windows.
+command launched on your machine. Can also reference other variables in the command, e.g. `echo ${MY_OTHER_VAR}-suffix`. For compatibility reasons, this command will be executed in an emulated shell on Windows.
 
 One example would be to forward ENV variables from your machine to the provider,
 for example:
@@ -143,7 +143,7 @@ for example:
     command: printf "%s" "${AWS_SECRET_ACCESS_KEY:-}"
 ```
 
-Or running an helper command (defined in the binaries section), and forward the result as the option's value:
+Or running an helper command (defined in the binaries section), and forwarding the result as the option's value:
 
 ```yaml
   AWS_TOKEN:

docs/pages/developing-providers/quickstart.mdx

@@ -105,7 +105,7 @@ In the `exec` section of the `provider.yaml`, the following commands are allowed
   - NotFound: Machine is not found
 
 :::info Windows Compatibility
-DevPod will execute these commands on unix systems directly in a POSIX shell, while on Windows in an [emulated shell](https://github.com/mvdan/sh) to provide compatibility. However, not all commands, such as `grep`, `sed` etc. are available there and if needed, such functionality should be transferred to a small helper binary DevPod can download and install through the binaries section.
+DevPod will execute these commands on Unix systems directly in a POSIX shell, while on Windows in an [emulated shell](https://github.com/mvdan/sh) to provide compatibility. However, not all commands, such as `grep`, `sed` etc. are available there and if needed, such functionality should be transferred to a small helper binary DevPod can download and install through the binaries section.
 :::
 
 For example, taking the [SSH Provider](https://github.com/loft-sh/devpod-provider-ssh):
@@ -162,7 +162,7 @@ Head over to the [Options Page](./options.mdx) to know more about how to set the
 ### Agent
 
 One important part of the lifecycle management of the DevPod's provider's resources is the **Agent**.
-The agent is an helper that DevPod will inject into the workspace in order to perform utilities like:
+The agent is a helper that DevPod will inject into the workspace in order to perform utilities like:
 
 - auto-shutdown the VM after inactivity
 - inject git credentials

docs/pages/managing-providers/add-provider.mdx

@@ -39,7 +39,7 @@ Under the hood, the Desktop Application will call a `devpod provider add PROVIDE
 
 ### Adding a custom provider
 
-After you clicked the `Add` button in the `Providers` section, you can click the
+After you click the `Add` button in the `Providers` section, you can click the
 big `+` button to add a custom provider, then fill the `Source` section with either
 
 - A GitHub link to the provider's project
@@ -72,7 +72,7 @@ You can specify a custom provider, directly from GitHub, by using the format
 devpod provider add loft-sh/devpod-provider-terraform
 ```
 
-DevPod will search the latest release for a `provider.yaml` and download that automatically. This should work for private github repositories where DevPod will use the local https credentials to connect to the GitHub repository.
+DevPod will search the latest release for a `provider.yaml` and download that automatically. This should work for private GitHub repositories where DevPod will use the local https credentials to connect to the GitHub repository.
 
 If you want to install the provider from a different release, you can do the following:
 ```sh
@@ -135,13 +135,13 @@ An example output for the AWS Provider is:
 ----------------------------+----------+--------------------------------+-------------------------+--------------------------
 AGENT_PATH                | false    | The path where to inject the   | /var/lib/toolbox/devpod | /var/lib/toolbox/devpod  
                           |          | DevPod agent to.               |                         |                          
-AWS_ACCESS_KEY_ID         | false    | The aws access key id          |                         |                          
+AWS_ACCESS_KEY_ID         | false    | The AWS access key id          |                         |                          
 AWS_AMI                   | false    | The disk image to use.         |                         |                          
 AWS_DISK_SIZE             | false    | The disk size to use.          | 40                      | 40                       
 AWS_INSTANCE_TYPE         | false    | The machine type to use.       | c5.xlarge               | c5.xlarge                
-AWS_REGION                | true     | The aws cloud region to create |                         | us-west-2                
+AWS_REGION                | true     | The AWS cloud region to create |                         | us-west-2                
                           |          | the VM in. E.g. us-west-1      |                         |                          
-AWS_SECRET_ACCESS_KEY     | false    | The aws secret access key      |                         |                          
+AWS_SECRET_ACCESS_KEY     | false    | The AWS secret access key      |                         |                          
 AWS_VPC_ID                | false    | The vpc id to use.             |                         |                          
 INACTIVITY_TIMEOUT        | false    | If defined, will automatically | 10m                     | 10m                      
                           |          | stop the VM after the          |                         |                          
@@ -154,7 +154,7 @@ INJECT_GIT_CREDENTIALS    | false    | If DevPod should inject git    | true
                           |          | host.                          |                         |  
 ```
 
-You can see this table as an overview, you can the change each option using:
+You can see this table as an overview, you can change each option using:
 
 ```sh
 devpod provider set-options <provider-name> --option <KEY>=<VALUE>
@@ -194,7 +194,7 @@ INJECT_GIT_CREDENTIALS    | false    | If DevPod should inject git    | true
 
 ## Single Machine Provider
 
-By default DevPod will use a separate machine for each workspace using the same provider,
+By default, DevPod will use a separate machine for each workspace using the same provider,
 you can enable `Reuse machine` in a provider in order to use a single machine for all workspaces.
 
 In **the desktop app** the option is available in the option management interface for the provider

docs/pages/managing-providers/update-provider.mdx

@@ -4,7 +4,7 @@ sidebar_label: Update a Provider
 ---
 
 
-To update a provider to its latest version, you can simply use:
+To update a provider to its latest version, you can use:
 
 ```sh
 devpod provider update <name>
@@ -17,7 +17,7 @@ for a provider.
 
 ## From GitHub
 
-Similar to adding a provider, you can simply update via:
+Similar to adding a provider, you can update via:
 ```sh
 devpod provider update <provider-name> my-org/my-repo
 ```