From 476bdee53892aeb97304db3ce54465a2b9971132 Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 14:12:40 +0200
Subject: [PATCH 1/9] Use bitops.config.yaml instead of .yml

---
 docs/configuration-base.md        |  2 +-
 docs/lifecycle.md                 | 10 +++++-----
 docs/operations-repo-structure.md |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/docs/configuration-base.md b/docs/configuration-base.md
index 71fa4f87..05710b31 100644
--- a/docs/configuration-base.md
+++ b/docs/configuration-base.md
@@ -1,6 +1,6 @@
 # Base Configuration
 
-Each deployment tool is traditionally controlled with a set of cli arguments. Instead of defining arguments within your pipeline configuration, they can instead either be defined with environment variables or in a `bitops.config.yml` file. While the core schema for a `bitops.config.yml` file is common between tools, the specific properties and environment variable equivilants vary from tool to tool.
+Each deployment tool is traditionally controlled with a set of cli arguments. Instead of defining arguments within your pipeline configuration, they can instead either be defined with environment variables or in a `bitops.config.yaml` file. While the core schema for a `bitops.config.yaml` file is common between tools, the specific properties and environment variable equivilants vary from tool to tool.
 
 > For more information on tool configuration, see [plugins](plugins.md).
 
diff --git a/docs/lifecycle.md b/docs/lifecycle.md
index 1d0d9fd4..cbdab2c2 100644
--- a/docs/lifecycle.md
+++ b/docs/lifecycle.md
@@ -3,7 +3,7 @@
 ## Lifecycle hooks
 Within each tool directory, you can optionally have a `bitops.before-deploy.d/` and/or a `bitops.after-deploy.d/`. If any shell scripts exist within these directories, BitOps will execute them in alphanumeric order.
 
-This is a useful way to extend the functionality of BitOps. A popular usecase we've seen is loading secrets or dynamically editing `bitops.config.yml`
+This is a useful way to extend the functionality of BitOps. A popular usecase we've seen is loading secrets or dynamically editing `bitops.config.yaml`
 
 ## Detailed Execution Flow
 
@@ -15,7 +15,7 @@ A single run of BitOps will
 2. Attempt to setup a cloud provider
 3. If a `terraform/` directory exists within the selected environment
     * Run any `bitops.before-deploy.d/*.sh` scripts 
-    * Load `bitops.config.yml` and set environment
+    * Load `bitops.config.yaml` and set environment
     * Merge contents with [Default environment](default-environment.md) - [TODO](https://github.com/bitovi/bitops/issues/18)
     * Select terraform version
     * Run `terraform init`
@@ -25,14 +25,14 @@ A single run of BitOps will
     * Run any `bitops.after-deploy.d/*.sh` scripts
 4. If a `ansible/` directory exists within the selected environment
     * Run any `bitops.before-deploy.d/*.sh` scripts
-    * Load `bitops.config.yml` and set environment
+    * Load `bitops.config.yaml` and set environment
     * Merge contents with [Default environment](default-environment.md) - [TODO](https://github.com/bitovi/bitops/issues/18)
     * Run `ansible-playbook $playbook` for each `*.yaml` or `*.yml` file in `$env/ansible/` 
     * Run any `bitops.after-deploy.d/*.sh` scripts
 4. If a `helm/` directory exists within the selected environment
     * Run the following for `$env/helm/$ENVIRONMENT_HELM_SUBDIRECTORY/` or for all charts in `$env/helm/`
         * Run any `bitops.before-deploy.d/*.sh` scripts
-        * Load `bitops.config.yml` and set environment
+        * Load `bitops.config.yaml` and set environment
         * Merge contents with [Default environment](default-environment.md)
         * Use `$KUBE_CONFIG_PATH` if defined, if not use aws cli to build .kubeconfig
         * Gather all values files - TODO document
@@ -43,7 +43,7 @@ A single run of BitOps will
         * TODO `helm_install_external_charts` and `helm_install_charts_from_s3` never run!
 4. If a `cloudformation/` directory exists within the selected environment
     * Run any `bitops.before-deploy.d/*.sh` scripts
-    * Load `bitops.config.yml` and set environment
+    * Load `bitops.config.yaml` and set environment
     * Merge contents with [Default environment](default-environment.md) - [TODO](https://github.com/bitovi/bitops/issues/18)
     * Run cfn template validation
     * Create or delete cfn stack. Wait for completion
diff --git a/docs/operations-repo-structure.md b/docs/operations-repo-structure.md
index 2a7e3268..eedd9233 100644
--- a/docs/operations-repo-structure.md
+++ b/docs/operations-repo-structure.md
@@ -19,7 +19,7 @@ BitOps expects an operations repo to be in the following structure, where each e
 │   └── terraform
 │       ├── bitops.after-deploy.d
 │       ├── bitops.before-deploy.d
-│       └── bitops.config.yml
+│       └── bitops.config.yaml
 └── dev
     ├── ansible
     │   ├── bitops.after-deploy.d

From 735a9179d4daeea10cb808fe2db53a05370834e0 Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 15:15:55 +0200
Subject: [PATCH 2/9] Various documentation fixes

---
 docs/configuration-base.md        | 6 +++---
 docs/operations-repo-structure.md | 5 ++---
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/docs/configuration-base.md b/docs/configuration-base.md
index 05710b31..21fe145c 100644
--- a/docs/configuration-base.md
+++ b/docs/configuration-base.md
@@ -1,6 +1,6 @@
 # Base Configuration
 
-Each deployment tool is traditionally controlled with a set of cli arguments. Instead of defining arguments within your pipeline configuration, they can instead either be defined with environment variables or in a `bitops.config.yaml` file. While the core schema for a `bitops.config.yaml` file is common between tools, the specific properties and environment variable equivilants vary from tool to tool.
+Each deployment tool is traditionally controlled with a set of cli arguments. Instead of defining arguments within your pipeline configuration, they can instead either be defined with environment variables or in a `bitops.config.yaml` file. While the core schema for a `bitops.config.yaml` file is common between tools, the specific properties and environment variable equivalents vary from tool to tool.
 
 > For more information on tool configuration, see [plugins](plugins.md).
 
@@ -12,6 +12,7 @@ $tool
   cli: {}
   options: {}
 ```
+
 * `$tool` - identifies the deployment tool
 * `cli` - object that contains cli arguments
 * `options` - object that offers additional control over how a tool executes
@@ -25,7 +26,6 @@ There are some global configuration options that are shared among all tools and
 -------------------
 ### environment
 * **Environment Variable:** `BITOPS_ENVIRONMENT`
-* **default:** `""`
 * **required:** yes
 
 Each BitOps run is done against a single environment. This property tells BitOps which environment to run. For more information on environments, see [Operations Repo Structure](operations-repo-structure.md#environment-directories).
@@ -36,7 +36,7 @@ Each BitOps run is done against a single environment. This property tells BitOps
 * **default:** `""`
 * **required:** no
 
-Base64 encoded `kubeconfig` file. Allows deployment tools to interact with a kubernetes cluster
+Base64 encoded `kubeconfig` file. Allows deployment tools to interact with a kubernetes cluster.
 
 -------------------
 ### default_replace
diff --git a/docs/operations-repo-structure.md b/docs/operations-repo-structure.md
index eedd9233..3b809ff0 100644
--- a/docs/operations-repo-structure.md
+++ b/docs/operations-repo-structure.md
@@ -1,5 +1,5 @@
 # Operations Repo Structure
-BitOps expects an operations repo to be in the following structure, where each enironment is in the root of the repository.  Each environment then contains folders for each tool, and each tool has a bitops.config.yaml.  There are also directories that can contain before and after scripts for each tool.
+BitOps expects an operations repo to be in the following structure, where each enironment is in the root of the repository.  Each environment then contains folders for each tool, and each tool has a `bitops.config.yaml`.  There are also directories that can contain _before_ and _after_ scripts for each tool.
 ```
 ├── production
 │   ├── ansible
@@ -69,5 +69,4 @@ chmod +x bitops.after-deploy.d/*
 ```
 
 #### bitops.config.yaml
-Each tool is traditionally controlled with a set of cli arguements. Instead of defining these cli arguments within your pipeline configuration, these arguements can instead be defined using environment variables or within a `bitops.config.yaml` file. While the core schema for this file is common betwen tools, the specific properties and environment variable equivilants vary from tool to tool. See [BitOps Configuration](configuration-base.md) for details.
-
+Each tool is traditionally controlled with a set of cli arguements. Instead of defining these cli arguments within your pipeline configuration, these arguements can instead be defined using environment variables or within a `bitops.config.yaml` file. While the core schema for this file is common betwen tools, the specific properties and environment variable equivalents vary from tool to tool. See [BitOps Configuration](configuration-base.md) for details.

From ce559ab2840ee2513a3ac2f5af3c2157a778e507 Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 15:42:51 +0200
Subject: [PATCH 3/9] Enhance the AWS documentation page

---
 docs/cloud-configuration/configuration-aws.md | 24 +++++++++----------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/docs/cloud-configuration/configuration-aws.md b/docs/cloud-configuration/configuration-aws.md
index 8a8c21b9..ee2454bd 100644
--- a/docs/cloud-configuration/configuration-aws.md
+++ b/docs/cloud-configuration/configuration-aws.md
@@ -2,7 +2,7 @@ Note from the developers: We are currently in the process of moving our document
 
 # AWS
 
-`bitops.config.yaml` is not yet supported for AWS ([TODO](https://github.com/bitovi/bitops/issues/15)). All configuration must be done with environment variables
+> ⚠️ `bitops.config.yaml` is not yet supported for AWS ([TODO](https://github.com/bitovi/bitops/issues/15)). All configuration must be done with environment variables.
 
 ## Configuration
 
@@ -13,7 +13,7 @@ Note from the developers: We are currently in the process of moving our document
 * **default:** `""`
 * **required:** yes
 
-AWS Access. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
+Specifies an AWS access key associated with an IAM user or role. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
 
 -------------------
 ### aws_secret_access_key
@@ -22,24 +22,24 @@ AWS Access. See [AWS official documentation](https://docs.aws.amazon.com/general
 * **default:** `""`
 * **required:** yes
 
-AWS Access. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
+Specifies the secret key associated with the access key. This is essentially the "password" for the access key. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
 
 -------------------
-### aws_session_token
+### aws_default_region
 * **BitOps Property:** [TODO](https://github.com/bitovi/bitops/issues/15)
-* **Environment Variable:** `AWS_SESSION_TOKEN`
+* **Environment Variable:** `AWS_DEFAULT_REGION`
 * **default:** `""`
-* **required:** no
+* **required:** yes
 
-AWS Access. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
+Specifies the AWS Region to send the request to. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
 
 -------------------
-### aws_default_region
+### aws_session_token
 * **BitOps Property:** [TODO](https://github.com/bitovi/bitops/issues/15)
-* **Environment Variable:** `AWS_DEFAULT_REGION`
+* **Environment Variable:** `AWS_SESSION_TOKEN`
 * **default:** `""`
-* **required:** yes
+* **required:** no
 
-AWS Access. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
+Specifies the session token value that is required if you are using temporary security credentials that you retrieved directly from AWS STS operations. See [AWS official documentation](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#access-keys-and-secret-access-keys)
 
--------------------
\ No newline at end of file
+-------------------

From 0f8f0bb6d8e2e4fe0855de99bfdc06d09b38c656 Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 17:56:55 +0200
Subject: [PATCH 4/9] Cleanup and minify the 2.0 migration guide

---
 docs/migration/2.0-migration.md | 104 ++++++++++++--------------------
 1 file changed, 39 insertions(+), 65 deletions(-)

diff --git a/docs/migration/2.0-migration.md b/docs/migration/2.0-migration.md
index 607fdd49..73e316aa 100644
--- a/docs/migration/2.0-migration.md
+++ b/docs/migration/2.0-migration.md
@@ -1,46 +1,30 @@
 Here is the list of major breaking changes that you need to be aware of when migrating from BitOps `v1.0` to `v2.0`.
 
-# Bitops Core
+## BitOps Core
 
-## Environment Variables
-### ENVIRONMENT
-Bitops is no longer using the `ENVIRONMENT` value, it instead uses; `BITOPS_ENVIRONMENT`
+### CHANGED: `ENVIRONMENT` -> `BITOPS_ENVIRONMENT` var
+BitOps is no longer using the `ENVIRONMENT` value, it instead uses `BITOPS_ENVIRONMENT`.
+Please rename your variables.
 
-Easiest migration solution; 
-Update startup command to read as followed;
-```
-docker run \
--e BITOPS_ENVIRONMENT=$ENVIRONMENT   \    <-- If the ENVIRONMENT variable is being used. This is a simple approach. 
--v /path/to/ops_repo:/opt/bitops_deployment    \
-bitovi/bitops:latest
-```
-
-### DEFAULT_FOLDER
-You can now control the default folder name with the environment variable `BITOPS_DEFAULT_FOLDER`
-
-### New Prefixes
-BitOps core exported environment variables now have a prefix of `BITOPS_`
+### CHANGED: `BITOPS_` Export Prefixes
+BitOps core exported environment variables now have a prefix of `BITOPS_`.
 
 **Examples**
-- BITOPS_TERRAFORM_ENV_VAR
-- BITOPS_ANSIBLE_ENV_VAR
 
+- `BITOPS_TERRAFORM_ENV_VAR`
+- `BITOPS_ANSIBLE_ENV_VAR`
 
-# Tool-level BitOps configs (i.e. bitops.config.yaml) in Operations Repo environments
-## stack-action
-ops_repo level bitops.config.yaml have had one important update; The cli attribute "stack-action" has been added. This attribute is used to tell the BitOps plugin which method it is invoking. 
+### CHANGED: `bitops.config.yaml` stack-action
+Ops repo level `bitops.config.yaml` have had one important update; The CLI attribute `stack-action` has been added. This attribute is used to tell the BitOps plugin which method it is invoking.
 
-For example, the terraform plugin, has 3 stack-actions;
-- apply
-- plan
-- destroy
+For example, the terraform plugin has 3 stack-actions: `plan`, `apply`, `destroy`.
 
 **Old method**
 ```
 terraform:
-    cli: {}
-    options:
-        command: apply
+  cli: {}
+  options:
+    command: apply
 ```
 
 **New method**
@@ -50,11 +34,10 @@ terraform:
     stack-action: apply
 ```
 
-**Reasoning for the change**
-This pattern is used by BitOps to standardize how a plugin specifies an action
+This pattern is now used by BitOps to standardize how a plugin specifies an action.
 
-## default_folder
-New attribute added to bitops.config.yaml to define the default folder name. This attribute is evaluated when building a bitops custom image. 
+### NEW: Default Folder Configuration
+A new attribute was added to `bitops.config.yaml` to define the default folder name. This attribute is evaluated when building a BitOps custom image.
 
 **New method**
 ```
@@ -62,56 +45,47 @@ bitops:
   default_folder: _default
 ```
 
-**Reasoning for the change**
-This provides more control to the bitops image builder. 
+The compatible environment variable to override this setting is `BITOPS_DEFAULT_FOLDER`.
 
 
-# Plugins
-## Ansible
-*changed attributes*
-
+## Plugins
+### Ansible
 *depreciated attributes*
-- ansible.cli.vault_id
-- ansible.cli.vault_password
-- ansible.options.verbosity
 
-*new attributes*
+- `ansible.cli.vault_id`
+- `ansible.cli.vault_password`
+- `ansible.options.verbosity`
 
 <hr/>
 
-## Terraform
-*changed attributes*
-
-*depreciated attributes*
-
+### Terraform
 *new attributes*
-- ansible.options.init-upgrade
+
+- `ansible.options.init-upgrade`
 
 <hr/>
 
-## Helm
+### Helm
 *changed attributes*
-- helm.options.uninstall-charts --> Changed to --> helm.options.uninstall
-- helm.option.kubeconfig.fetch.enabled --> Changed to --> helm.option.kubeconfig.fetch.fetch_kubeconfig
-
-*depreciated attributes*
 
+- `helm.options.uninstall-charts` --> Changed to --> `helm.options.uninstall`
+- `helm.option.kubeconfig.fetch.enabled` --> Changed to --> `helm.option.kubeconfig.fetch.fetch_kubeconfig`
 
 *new attributes*
-- helm.options.default-root-dir
-- helm.options.default-dir-flag
-- helm.options.default-sub-dir
+
+- `helm.options.default-root-dir`
+- `helm.options.default-dir-flag`
+- `helm.options.default-sub-dir`
 
 <hr/>
 
-## Cloudformation
+### Cloudformation
 *changed attributes*
-- cloudformation.options.cfn-files.parameters.enabled --> Changed to --> cloudformation.options.cfn-files.parameters.template-param-flag
-- cloudformation.options.cfn-files.parameters.template-file --> Changed to --> cloudformation.options.cfn-files.parameters.template-param-file
-
-*depreciated attributes*
 
+- `cloudformation.options.cfn-files.parameters.enabled` --> Changed to --> `cloudformation.options.cfn-files.parameters.template-param-flag`
+- `cloudformation.options.cfn-files.parameters.template-file` --> Changed to --> `cloudformation.options.cfn-files.parameters.template-param-file`
 
 *new attributes*
-- cloudformation.options.s3bucket
-- cloudformation.options.s3prefix
+
+- `cloudformation.options.s3bucket`
+- `cloudformation.options.s3prefix`

From cb788fc3662f1dd35cabf5e409f70f08c0c7c81d Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 17:58:08 +0200
Subject: [PATCH 5/9] Add a warning note to the docs

---
 docs/cloud-configuration/configuration-aws.md           | 2 +-
 docs/tool-configuration/configuration-ansible.md        | 2 +-
 docs/tool-configuration/configuration-cloudformation.md | 2 +-
 docs/tool-configuration/configuration-helm.md           | 2 +-
 docs/tool-configuration/configuration-terraform.md      | 6 +++---
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/docs/cloud-configuration/configuration-aws.md b/docs/cloud-configuration/configuration-aws.md
index ee2454bd..f412f3ff 100644
--- a/docs/cloud-configuration/configuration-aws.md
+++ b/docs/cloud-configuration/configuration-aws.md
@@ -1,4 +1,4 @@
-Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/aws) 
+> ⚠️ Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/aws).
 
 # AWS
 
diff --git a/docs/tool-configuration/configuration-ansible.md b/docs/tool-configuration/configuration-ansible.md
index db907035..f19aa68b 100644
--- a/docs/tool-configuration/configuration-ansible.md
+++ b/docs/tool-configuration/configuration-ansible.md
@@ -1,4 +1,4 @@
-Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/ansible) 
+> ⚠️ Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/ansible).
 
 # Ansible
 
diff --git a/docs/tool-configuration/configuration-cloudformation.md b/docs/tool-configuration/configuration-cloudformation.md
index be319edd..b00e9a55 100644
--- a/docs/tool-configuration/configuration-cloudformation.md
+++ b/docs/tool-configuration/configuration-cloudformation.md
@@ -1,4 +1,4 @@
-Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/cloudformation) 
+> ⚠️ Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/cloudformation).
 
 # Cloudformation
 
diff --git a/docs/tool-configuration/configuration-helm.md b/docs/tool-configuration/configuration-helm.md
index 9ab91ff9..a746cd82 100644
--- a/docs/tool-configuration/configuration-helm.md
+++ b/docs/tool-configuration/configuration-helm.md
@@ -1,4 +1,4 @@
-Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/helm) 
+> ⚠️ Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/helm).
 
 # Helm
 
diff --git a/docs/tool-configuration/configuration-terraform.md b/docs/tool-configuration/configuration-terraform.md
index a62dc306..64fe647f 100644
--- a/docs/tool-configuration/configuration-terraform.md
+++ b/docs/tool-configuration/configuration-terraform.md
@@ -1,4 +1,4 @@
-Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/terraform) 
+> ⚠️ Note from the developers: We are currently in the process of moving our documentation and so the below documentation is only partially correct. For more information on this tool please checkout our [plugin documentation](https://github.com/bitops-plugins/terraform).
 
 # Bitops Plugin for Terraform
 ## Deployment
@@ -28,7 +28,7 @@ The `terraform` plugin will run `terraform init` and `terraform plan` on every e
 
 Run BitOps with the environmental variable `TERRAFORM_APPLY` set to `true` or set `stack-action` in the `bitops.config.yaml` file to apply to run `terraform apply`.
 
-## CLI and options configuration of Terraform``bitops.schema.yaml`
+## CLI and options configuration of Terraform `bitops.schema.yaml`
 
 ### Terraform BitOps Schema
 
@@ -97,7 +97,7 @@ Run BitOps with the environmental variable `TERRAFORM_APPLY` set to `true` or se
 -------------------
 
 ## Additional Environment Variable Configuration
-Although not captured in `bitops.config.yaml`, the following environment variables can be set to further customize behaviour.  Set the value of the environental variable to `true` to use
+Although not captured in `bitops.config.yaml`, the following environment variables can be set to further customize behaviour.  Set the value of the environental variable to `true` to enable its behavior.
 
 -------------------
 ### SKIP_DEPLOY_TERRAFORM

From 675ff933ac7c30265eb98650542025bcb3a5b109 Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 18:04:19 +0200
Subject: [PATCH 6/9] Grammar and formatting fixes

---
 docs/default-environment.md | 15 +++++++--------
 docs/examples.md            | 13 +++++++------
 mkdocs.yml                  |  2 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/docs/default-environment.md b/docs/default-environment.md
index c32a87bc..a45e6ba8 100644
--- a/docs/default-environment.md
+++ b/docs/default-environment.md
@@ -17,7 +17,7 @@ Suppose we are working with an operations repo that is exlusviely terraform. We
         └── bitops.config.yaml
         └── test.auto.tfvars
 ```
-When `$BITOPS_ENVIRONMENT` is set to `production`, `_default/` will be merged in to `production/` at runtime to produce a directory structure that looks like
+When `$BITOPS_ENVIRONMENT` is set to `production`, `_default/` will be merged into `production/` at runtime to produce a directory structure that looks this way:
 ```
 ├── _default
 │   └── terraform
@@ -33,7 +33,7 @@ When `$BITOPS_ENVIRONMENT` is set to `production`, `_default/` will be merged in
         └── test.auto.tfvars
 ```
 
-Things get more complex when files exist in both the `_default` and `active` environment share the same name. This is why we have file mergers.
+Things get more complex when files that exist in both the `_default` and `active` environment share the same name. This is why we have file mergers.
 
 
 ## File Mergers [TODO](https://github.com/bitovi/bitops/issues/3)
@@ -45,7 +45,7 @@ Files that only exist in the `_default` environment will be copied over.
 `.tf` files from the `_default` environment that share its name and path with a file in the active environment will both be in the resulting directory with the active environment name having a suffix added to it.
 
 #### Example
-Before default merge
+Before default merge:
 ```
 ├── _default
 │   └── terraform
@@ -55,7 +55,7 @@ Before default merge
         └── bitops.config.yaml
         └── main.tf
 ```
-After default merge
+After default merge:
 ```
 ├── _default
 │   └── terraform
@@ -109,7 +109,7 @@ Files that only exist in the `_default` environment will be copied over.
 Files from the `_default` environment that share its name and path will be merged.
 
 ### values.yaml (Helm)
-helm has built in support for merging multiple `values.yaml` files. BitOps will look for files in the following locations and pass them in to helm with with the `-f` in the same order they are found
+Helm has built in support for merging multiple `values.yaml` files. BitOps will look for files in the following locations and pass them in to helm with the `-f` in the same order they are found:
 
 1. Active environment's `values.yaml`
 2. Default environment's `values.yaml`
@@ -139,10 +139,9 @@ The following operations repo structure
 ```
 Will produce the following `helm install` command
 ```
-helm install my-first-chart/
 helm install \
-$HELM_RELEASE_NAME 
-my-first-chart/
+$HELM_RELEASE_NAME \ 
+my-first-chart \
 -f test/helm/my-first-chart/values.yaml \
 -f default/helm/my-first-chart/values.yaml \
 -f test/helm/my-first-chart/values-versions.yaml \
diff --git a/docs/examples.md b/docs/examples.md
index 547d623f..698dd409 100644
--- a/docs/examples.md
+++ b/docs/examples.md
@@ -37,8 +37,8 @@ docker run \
 bitovi/bitops:latest
 ```
 
-### Fetch kubeconfig from eks
-If you has a cluster arn of `arn:aws:eks:us-east-1:111122223333:cluster/my-cluster`, you would use the following configuration
+### Fetch kubeconfig from EKS
+If you have a cluster arn of `arn:aws:eks:us-east-1:111122223333:cluster/my-cluster`, you would use the following configuration:
 ```
 docker run \
 -e BITOPS_ENVIRONMENT="dev" \
@@ -51,7 +51,7 @@ bitovi/bitops:latest
 ```
 
 ### Force skip over ansible
-If there is a `dev/ansible/` directory, ansible execution can be skipped with `SKIP_DEPLOY_ANSIBLE`
+If there is a `./dev/ansible/` directory, ansible execution can be skipped with `SKIP_DEPLOY_ANSIBLE=true`:
 ```
 docker run \
 -e BITOPS_ENVIRONMENT="dev" \
@@ -75,13 +75,14 @@ docker run \
 bitovi/bitops:latest
 ```
 
-## Use your local BitOps
+## Use your local BitOps code
+If you'd like to override the BitOps code with your own version, see how to do that with the `$BITOPS_HOME` example:
 ```
 docker run 
 -e AWS_DEFAULT_REGION=$AWS_DEFAULT_REGION           \
 -e AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID             \
 -e AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY     \
--e BITOPS_ENVIRONMENT="test"                               \
+-e BITOPS_ENVIRONMENT="test"                        \
 -v $(pwd):/opt/bitops_deployment                    \
 -v $BITOPS_HOME:/opt/bitops                         \
 bitovi/bitops:latest
@@ -92,7 +93,7 @@ bitovi/bitops:latest
 ### Using Declarative Infrastructure to Deploy an EKS Cluster and Helm Chart
 * [Using Declarative Infrastructure to Deploy an EKS Cluster and Helm Chart](https://www.bitovi.com/blog/eks-helm-bitops)
 
-### Bitops and Terraform
+### BitOps and Terraform
 * [BitOps + Terraform](https://www.bitovi.com/blog/bitops-terraform)
 
 ### Combine Terraform and Ansible to provision and configure a webserver
diff --git a/mkdocs.yml b/mkdocs.yml
index f3518568..fa6f265e 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -38,7 +38,7 @@ nav:
     - BitOps Versioning: versioning.md
   - Examples: examples.md
   - Upgrade:
-    - 2.0: migration/2.0-migration.md
+    - v2.0: migration/2.0-migration.md
   - Development:
     - Local development: development-local.md
     - Custom Images: custom-image.md

From 88ee485fdf03fc2cdda912b9b12a829f7971dc5f Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 22:25:50 +0200
Subject: [PATCH 7/9] Docs fixes: typos, formatting, invalid references,
 grammar

---
 docs/configuration-base.md        | 14 +++++++-------
 docs/development-local.md         | 17 ++++++++---------
 docs/development/development.md   |  6 +-----
 docs/getting-started.md           |  7 +++----
 docs/lifecycle.md                 | 20 +++++++++-----------
 docs/operations-repo-structure.md | 14 +++++++-------
 docs/plugins.md                   | 19 +++++++++++--------
 docs/versioning.md                |  4 ++--
 8 files changed, 48 insertions(+), 53 deletions(-)

diff --git a/docs/configuration-base.md b/docs/configuration-base.md
index 21fe145c..03ede2e1 100644
--- a/docs/configuration-base.md
+++ b/docs/configuration-base.md
@@ -1,6 +1,6 @@
 # Base Configuration
 
-Each deployment tool is traditionally controlled with a set of cli arguments. Instead of defining arguments within your pipeline configuration, they can instead either be defined with environment variables or in a `bitops.config.yaml` file. While the core schema for a `bitops.config.yaml` file is common between tools, the specific properties and environment variable equivalents vary from tool to tool.
+Each deployment tool is traditionally controlled with a set of CLI arguments. Instead of defining arguments within your pipeline configuration, they can instead either be defined with environment variables or in a `bitops.config.yaml` file. While the core schema for a `bitops.config.yaml` file is common between tools, the specific properties and environment variable equivalents vary from tool to tool.
 
 > For more information on tool configuration, see [plugins](plugins.md).
 
@@ -14,11 +14,11 @@ $tool
 ```
 
 * `$tool` - identifies the deployment tool
-* `cli` - object that contains cli arguments
-* `options` - object that offers additional control over how a tool executes
+* `cli` - object that contains CLI arguments
+`options` - an object that offers additional control over how a tool executes
 
 ## Arbitrary Environment Variables
-During the docker run command, you can specify a ENV var and it will be accessible during all processing stages of BitOps. 
+During the docker run command, you can specify an ENV var and it will be accessible during all processing stages of BitOps. 
 
 ## Common Configuration
 There are some global configuration options that are shared among all tools and cloud providers during a BitOps run. These are set via environment variables
@@ -36,14 +36,14 @@ Each BitOps run is done against a single environment. This property tells BitOps
 * **default:** `""`
 * **required:** no
 
-Base64 encoded `kubeconfig` file. Allows deployment tools to interact with a kubernetes cluster.
+Base64 encoded `kubeconfig` file. Allows deployment tools to interact with a Kubernetes cluster.
 
 -------------------
 ### default_replace
 * **Environment Variable:** `BITOPS_DEFAULT_REPLACE`
 * **default:** `false`
 
-If true, [file mergers](default-environment.md) will replace instead of create a copy during a merge
+If true, [file mergers](default-environment.md) will replace instead of creating a copy during a merge.
 
 -------------------
 ### skip_if_no_environment_changes
@@ -51,7 +51,7 @@ If true, [file mergers](default-environment.md) will replace instead of create a
 * **default:** `""`
 * **required:** no
 
-If nonempty, will evaluate the `git diff` to see if there are any changes in the specified `BITOPS_ENVIRONMENT` and will `exit 0` if not.
+If non-empty, it will evaluate the `git diff` to see if there are any changes in the specified `BITOPS_ENVIRONMENT` and will `exit 0` if not.
 
 -------------------
 ## Cloud Providers
diff --git a/docs/development-local.md b/docs/development-local.md
index 6bd3dd8a..6d8d6b1a 100644
--- a/docs/development-local.md
+++ b/docs/development-local.md
@@ -1,15 +1,15 @@
-At this point you should have a repo for your custom BitOps image and have it open in your favorite editor. For more information on setting up your [custom BitOps image](custom-image.md)
+At this point, you should have a repo for your custom BitOps image and have it open in your favorite editor. For more information on setting up your [custom BitOps image](custom-image.md)
 
 
-## Create a plugins.dockerfile
-Create a file in the root level of BitOps named `Dockerfile.plugins` with the content; 
-
-`FROM bitovi/bitops:2.0.0`
+## Create plugins Dockerfile
+Create a file in the root level of BitOps named `Dockerfile.plugins` with the following content:
 
+```
+FROM bitovi/bitops:base
+```
 
 ## Build BitOps (with plugins)
-`docker build -t bitops:latest . -f Dockerfile.plugins`
-
+`docker build -t bitops:local . -f Dockerfile.plugins`
 
 ## Run BitOps
 ```
@@ -19,10 +19,9 @@ docker run \
   -e AWS_ACCESS_KEY_ID=your-aws-access-key \
   -e AWS_SECRET_ACCESS_KEY=your-aws-secret-access-key \
   -v /path/to/operations_repo:/opt/bitops_deployment \
-  bitops:latest
+  bitops:local
 ```
 
-
 # Benefits to local testing
 - configuration validation
 - rapid testing of new features
diff --git a/docs/development/development.md b/docs/development/development.md
index 0dc66975..24e82345 100644
--- a/docs/development/development.md
+++ b/docs/development/development.md
@@ -80,9 +80,6 @@ A `*` denotes a required variable.
 | `$TEMPDIR`        | `/tmp/tmp.RANDOM`                  |   This is the randomly generated working dir for BitOps.  |
 | `$ROOT_DIR`        | `/opt/bitops_deployment`                  |   This working dir for BitOps (moved to `$TEMPDIR` during execution)  |
 
-> For more information about the core variables, see
-> [scripts/deploy.sh](https://github.com/bitovi/bitops/blob/master/scripts/deploy.sh)
-
 ### Standard BitOps Packages and Libraries:
 
 System Packages natively available in a running BitOps container:
@@ -109,8 +106,7 @@ Python packages natively available in BitOps:
 * shyaml
 * wheel
 
-> For the most up-to-date list, see
-> - [requirements.txt](https://github.com/bitovi/bitops/blob/master/requirements.txt)
+> For the most up-to-date list, see [requirements.txt](https://github.com/bitovi/bitops/blob/main/requirements.txt)
 
 ### BitOps Code Structure:
 
diff --git a/docs/getting-started.md b/docs/getting-started.md
index bc91eff9..c3167c40 100644
--- a/docs/getting-started.md
+++ b/docs/getting-started.md
@@ -27,20 +27,20 @@ See [configuration](configuration-base.md)
 
 ## Run BitOps
 
-BitOps is packaged as a docker image and is available on [dockerhub](https://hub.docker.com/r/bitovi/bitops).
+BitOps is packaged as a docker image and is available on [docker hub](https://hub.docker.com/r/bitovi/bitops).
 
 ```
 docker pull bitovi/bitops
 cd $YOUR_OPERATIONS_REPO
 docker run bitovi/bitops -v $(pwd):/opt/bitops_deployment
 ```
-If you need specific version of BitOps, please check the [BitOps versioning](versioning.md).
+If you need a specific version of BitOps, please check the [BitOps versioning](versioning.md).
 
 ## Supported Tools
 * [Provision infrastructure with CloudFormation](tool-configuration/configuration-cloudformation.md)
 * [Provision infrastructure with Terraform](tool-configuration/configuration-terraform.md)
 * [Configure infrastructure with Ansible](tool-configuration/configuration-ansible.md)
-* [Deploy to kubernetes with Helm](tool-configuration/configuration-helm.md)
+* [Deploy to Kubernetes with Helm](tool-configuration/configuration-helm.md)
 
 ## Supported Cloud Providers
 
@@ -51,4 +51,3 @@ If you need specific version of BitOps, please check the [BitOps versioning](ver
 ## Guides and Other Resources
 
 BitOps already has several guides demonstrating deploying a web server or a pre-configured application using different combinations of the available BitOps tools. If you're looking for a quick start, check out some of the options available in the [Examples](examples.md) section.
-
diff --git a/docs/lifecycle.md b/docs/lifecycle.md
index cbdab2c2..5a959873 100644
--- a/docs/lifecycle.md
+++ b/docs/lifecycle.md
@@ -3,17 +3,17 @@
 ## Lifecycle hooks
 Within each tool directory, you can optionally have a `bitops.before-deploy.d/` and/or a `bitops.after-deploy.d/`. If any shell scripts exist within these directories, BitOps will execute them in alphanumeric order.
 
-This is a useful way to extend the functionality of BitOps. A popular usecase we've seen is loading secrets or dynamically editing `bitops.config.yaml`
+This is a useful way to extend the functionality of BitOps. A popular use case we've seen is loading secrets, preparing the environment or dynamically editing `bitops.config.yaml`.
 
 ## Detailed Execution Flow
 
 ![lifecycle diagram](assets/images/lifecycle.png)
 
-A single run of BitOps will
+A single run of BitOps will:
 
 1. Copy the contents of `/opt/bitops_deployment` to a temporary working directory
 2. Attempt to setup a cloud provider
-3. If a `terraform/` directory exists within the selected environment
+3. If a `terraform/` directory exists within the selected environment:
     * Run any `bitops.before-deploy.d/*.sh` scripts 
     * Load `bitops.config.yaml` and set environment
     * Merge contents with [Default environment](default-environment.md) - [TODO](https://github.com/bitovi/bitops/issues/18)
@@ -23,25 +23,25 @@ A single run of BitOps will
     * Run `terraform plan`
     * Run `terraform apply` or `terraform destroy`
     * Run any `bitops.after-deploy.d/*.sh` scripts
-4. If a `ansible/` directory exists within the selected environment
+4. If a `ansible/` directory exists within the selected environment:
     * Run any `bitops.before-deploy.d/*.sh` scripts
     * Load `bitops.config.yaml` and set environment
     * Merge contents with [Default environment](default-environment.md) - [TODO](https://github.com/bitovi/bitops/issues/18)
     * Run `ansible-playbook $playbook` for each `*.yaml` or `*.yml` file in `$env/ansible/` 
     * Run any `bitops.after-deploy.d/*.sh` scripts
-4. If a `helm/` directory exists within the selected environment
+4. If a `helm/` directory exists within the selected environment:
     * Run the following for `$env/helm/$ENVIRONMENT_HELM_SUBDIRECTORY/` or for all charts in `$env/helm/`
         * Run any `bitops.before-deploy.d/*.sh` scripts
         * Load `bitops.config.yaml` and set environment
         * Merge contents with [Default environment](default-environment.md)
-        * Use `$KUBE_CONFIG_PATH` if defined, if not use aws cli to build .kubeconfig
+        * Use `$KUBE_CONFIG_PATH` if defined, if not use AWS CLI to build `.kubeconfig`
         * Gather all values files - TODO document
         * Run `helm dep up`
         * Run `helm upgrade` or `helm install`
         * Run `helm rollback` on failure
         * Run any `bitops.after-deploy.d/*.sh` scripts
         * TODO `helm_install_external_charts` and `helm_install_charts_from_s3` never run!
-4. If a `cloudformation/` directory exists within the selected environment
+4. If a `cloudformation/` directory exists within the selected environment:
     * Run any `bitops.before-deploy.d/*.sh` scripts
     * Load `bitops.config.yaml` and set environment
     * Merge contents with [Default environment](default-environment.md) - [TODO](https://github.com/bitovi/bitops/issues/18)
@@ -50,8 +50,6 @@ A single run of BitOps will
     * Run any `bitops.after-deploy.d/*.sh` scripts
 
 ### Environment Variables
-Plugins can export environment when a value is specified in a ops_repo level `bitops.config.yaml`. These environment variables are prefixed with `BITOPS` and their plugin name. 
+Plugins can export the environment when a value is specified in an ops_repo level `bitops.config.yaml`. These environment variables are prefixed with `BITOPS_` and their plugin name. 
 
-So for example, if the terraform plugin exported the environment variable BUTTER_FLAG, it would be accessible in the lifecycle hooks by referencing; 
-
-`BITOPS_TERRAFORM_BUTTER_FLAG`
+So for example, if the terraform plugin exported the environment variable `BUTTER_FLAG`, it would be accessible in the lifecycle hooks by referencing `BITOPS_TERRAFORM_BUTTER_FLAG`.
diff --git a/docs/operations-repo-structure.md b/docs/operations-repo-structure.md
index 3b809ff0..ed1023a1 100644
--- a/docs/operations-repo-structure.md
+++ b/docs/operations-repo-structure.md
@@ -1,5 +1,5 @@
 # Operations Repo Structure
-BitOps expects an operations repo to be in the following structure, where each enironment is in the root of the repository.  Each environment then contains folders for each tool, and each tool has a `bitops.config.yaml`.  There are also directories that can contain _before_ and _after_ scripts for each tool.
+BitOps expects an operations repo to be in the following structure, where each environment is in the root of the repository.  Each environment then contains folders for each tool, and each tool has a `bitops.config.yaml`.  There are also directories that can contain _before_ and _after_ scripts for each tool.
 ```
 ├── production
 │   ├── ansible
@@ -41,19 +41,19 @@ BitOps expects an operations repo to be in the following structure, where each e
         └── bitops.config.yaml
 ```
 #### Environment Directories
-These directories live at the root of an operations repository and are used to separate applications and environments. Depending on your usecase, you may have an environment for `production`, `test` and `dev` or these traditional environments may be further separated into individual services such as `test_service_a` and `test_serice_b`. This pattern is preferential to having a branch for each environment as this allows the state of all your infrastructure to be managed from one location without merging potentially breaking an environment.
+These directories live at the root of an operations repository and are used to separate applications and environments. Depending on your use case, you may have an environment for `production`, `test` and `dev` or these traditional environments may be further separated into individual services such as `test_service_a` and `test_serice_b`. This pattern is preferential to have a branch for each environment as this allows the state of all your infrastructure to be managed from one location without merging potentially breaking an environment.
 
 When running BitOps, you provide the environment variable `BITOPS_ENVIRONMENT`. This tells BitOps what environment to work in for that run. A full CI/CD pipeline may call BitOps multiple times if it requires one environment to run as a pre-requisite for another.
 
 #### Environment Directory Naming Convention
 Sometimes it is useful to have directories in your operations repo that are not deployable environments such as common scripts that can be referenced from any environment's [before or after hooks](lifecycle.md).
 
-BitOps allows you to name your environment directories whatever you want.  However, to better reason about which directories are environments and which aren't, a good convention is to prefix any non-deployable-environment directory with an underscore (e.g. `_scripts` or `_terraform`).  
+BitOps allows you to name your environment directories whatever you want.  However, to better reason about which directories are environments and which aren't a good convention is to prefix any non-deployable-environment directory with an underscore (e.g. `_scripts` or `_terraform`).
 
-The directory `_default` is special in BitOps.  This directory is merged into your environment directory before deployment. You can control the default folder name through an environment variable `BITOPS_DEFAULT_FOLDER` or through a bitops configuration attribute `bitops.default_folder`.
+The directory `_default` is special in BitOps.  This directory is merged into your environment directory before deployment. You can control the default folder name through an environment variable `BITOPS_DEFAULT_FOLDER` or through a BitOps configuration attribute `bitops.default_folder`.
 
 #### Tool directories
-Within an environment directory are tool directories which group supported tools by name. Each of these directories is optional. For example, if your application only requires `terraform/` to execute, you do not need an `ansible/`, `cloudformation/` or `helm/` directory in your environment.
+Within an environment directory are tool directories that group supported tools by name. Each of these directories is optional. For example, if your application only requires `terraform/` to execute, you do not need an `ansible/`, `cloudformation/` or `helm/` directory in your environment.
 
 This directory is also where you put your infrastructure code associated with the respective tool.
 
@@ -62,11 +62,11 @@ Helm has additional capabilities here. You can nest multiple charts within the `
 #### Lifecycle directories
 Within a tool directory, you can optionally have a `bitops.before-deploy.d/` and/or a `bitops.after-deploy.d/`. You can put arbitrary `*.sh` scripts in here and they will be run before or after the tool executes. More for information see [lifecycle](lifecycle.md) docs.
 
-If bitops is reporting it can't find your scripts, make sure the scripts have execute permissions.
+If BitOps is reporting it can't find your scripts, make sure the scripts have execute permissions.
 ```
 chmod +x bitops.before-deploy.d/*
 chmod +x bitops.after-deploy.d/*
 ```
 
 #### bitops.config.yaml
-Each tool is traditionally controlled with a set of cli arguements. Instead of defining these cli arguments within your pipeline configuration, these arguements can instead be defined using environment variables or within a `bitops.config.yaml` file. While the core schema for this file is common betwen tools, the specific properties and environment variable equivalents vary from tool to tool. See [BitOps Configuration](configuration-base.md) for details.
+Each tool is traditionally controlled with a set of CLI arguments. Instead of defining these CLI arguments within your pipeline configuration, these arguments can instead be defined using environment variables or within a `bitops.config.yaml` file. While the core schema for this file is common between tools, the specific properties and environment variable equivalents vary from tool to tool. See [BitOps Configuration](configuration-base.md) for details.
diff --git a/docs/plugins.md b/docs/plugins.md
index 9fd8f00c..9d1561ac 100644
--- a/docs/plugins.md
+++ b/docs/plugins.md
@@ -9,16 +9,19 @@ You can create your own BitOps image to customize runtime behavior by installing
 
 ## Pre-Built Images
 
-BitOps' default image contains BitOps base along with the following pre-installed plugins:
+BitOps' default image called `omnibus` contains BitOps `base` along with the following pre-installed plugins:
 
+* [bitops-aws-plugin](https://github.com/bitops-plugins/aws)
+* [bitops-cloudformation-plugin](https://github.com/bitops-plugins/cloudformation)
 * [bitops-terraform-plugin](https://github.com/bitops-plugins/terraform)
 * [bitops-ansible-plugin](https://github.com/bitops-plugins/ansible)
-* [bitops-cloudformation-plugin](https://github.com/bitops-plugins/cloudformation)
 * [bitops-helm-plugin](https://github.com/bitops-plugins/helm)
+* [bitops-kubectl-plugin](https://github.com/bitops-plugins/kubectl)
+
 
-> See [prebuilt-config](https://github.com/bitovi/bitops/tree/main/prebuilt-config) to see other available pre-built images.
+> See [prebuilt-config](https://github.com/bitovi/bitops/tree/main/prebuilt-config) for the list of other available pre-built images and [bitops images and versions](versioning.md) to understand how these images are named and tagged on Docker Hub.
 
-## Creating your own BitOps
+## Creating your own BitOps image
 To create your own BitOps, you will need two files:
 
 * **[bitops.config.yaml](../bitops.config.yaml)**: Contains configuration attributes that will modify how BitOps behaves
@@ -67,11 +70,11 @@ bitops:
       plugin: ansible
 
 ```
-The repo for each plugin must be a `git clone`-able url. The name can be anything.
+The repo for each plugin must be a `git clone`-able URL. The name can be anything.
 
-The order that plugins run is dependent on the `deployments` section. If a `depoyments` section isn't provided, it will attempt to process all folders in the `BITOPS_ENVIRONMENT` directory in alphabetical order.
+The order that plugins run is dependent on the `deployments` section. If a `deployments` section isn't provided, it will attempt to process all folders in the `BITOPS_ENVIRONMENT` directory in alphabetical order.
 
-**Dockerfile**
+### Dockerfile
 The only content that is needed to create a custom image is:
 
 ```
@@ -84,6 +87,6 @@ Creating a plugin is easy, you only need 4 files:
 * `install.sh` - This script is called during plugin installation (Docker build time). It should be used to install any dependencies needed for your plugin to function 
 * `deploy.sh` - The main entrypoint for your plugin at deploy time
 * `bitops.schema.yaml` - Defines the parameters users have access to. The corresponding `bitops.config.yaml` within the `BITOPS_ENVIRONMENT` folder will configure the parameter values.
-* `plugin.config.yaml` - A file used to describes the plugin configuration to BitOps 
+* `plugin.config.yaml` - A file used to describe the plugin configuration.
 
 > For more information, you can look at our [example plugin](https://github.com/bitops-plugins/example-plugin) repo that prints your name and favorite color!
diff --git a/docs/versioning.md b/docs/versioning.md
index b0a617f3..68341597 100644
--- a/docs/versioning.md
+++ b/docs/versioning.md
@@ -5,8 +5,8 @@ Here is how these images are named, versioned and tagged.
 * An image with a version tag containing a [semver](https://semver.org) (e.g. `2.0.0`) is immutable and refers to the [stable release](https://github.com/bitovi/bitops/releases).
 * A version tag equal to `latest` is always mutable and points to the latest [stable release](https://github.com/bitovi/bitops/releases).
 * A version tag containing `dev` is always mutable and refers to the current development state in the [`main`](https://github.com/bitovi/bitops/tree/main) repository branch.
-* A version tag containing `omnibus` points to the default image that includes recommended devops tools.
-* A version tag containing `base` refers to minimal image with no other tools. You can build a [custom BitOps image](plugins.md) from it.
+* A version tag containing `omnibus` points to the default image that includes recommended DevOps tools.
+* A version tag containing `base` refers to a minimal image with no other tools. You can build a [custom BitOps image](plugins.md) from it.
 
 ## Official Images
 To clear up any potential confusion regarding the versioning of the [`bitovi/bitops`](https://hub.docker.com/r/bitovi/bitops) image, we use the following table.

From d6afe0d901fee04dd030d93a80f2ea610a53ce21 Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Wed, 17 Aug 2022 22:31:42 +0200
Subject: [PATCH 8/9] Fix the broken list formatting

---
 docs/configuration-base.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/configuration-base.md b/docs/configuration-base.md
index 03ede2e1..169a71d9 100644
--- a/docs/configuration-base.md
+++ b/docs/configuration-base.md
@@ -15,7 +15,7 @@ $tool
 
 * `$tool` - identifies the deployment tool
 * `cli` - object that contains CLI arguments
-`options` - an object that offers additional control over how a tool executes
+* `options` - an object that offers additional control over how a tool executes
 
 ## Arbitrary Environment Variables
 During the docker run command, you can specify an ENV var and it will be accessible during all processing stages of BitOps. 

From 925eb2443597b49d00aec9bfbd8c25f9d66cfbc9 Mon Sep 17 00:00:00 2001
From: Eugen <1533818+armab@users.noreply.github.com>
Date: Mon, 22 Aug 2022 17:38:59 +0100
Subject: [PATCH 9/9] Small wording fix based on review

---
 docs/operations-repo-structure.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/operations-repo-structure.md b/docs/operations-repo-structure.md
index ed1023a1..321eae29 100644
--- a/docs/operations-repo-structure.md
+++ b/docs/operations-repo-structure.md
@@ -41,7 +41,7 @@ BitOps expects an operations repo to be in the following structure, where each e
         └── bitops.config.yaml
 ```
 #### Environment Directories
-These directories live at the root of an operations repository and are used to separate applications and environments. Depending on your use case, you may have an environment for `production`, `test` and `dev` or these traditional environments may be further separated into individual services such as `test_service_a` and `test_serice_b`. This pattern is preferential to have a branch for each environment as this allows the state of all your infrastructure to be managed from one location without merging potentially breaking an environment.
+These directories live at the root of an operations repository and are used to separate applications and environments. Depending on your use case, you may have an environment for `production`, `test` and `dev` or these traditional environments may be further separated into individual services such as `test_service_a` and `test_serice_b`. This pattern is preferential to having a branch for each environment as this allows the state of all your infrastructure to be managed from one location without merging potentially breaking an environment.
 
 When running BitOps, you provide the environment variable `BITOPS_ENVIRONMENT`. This tells BitOps what environment to work in for that run. A full CI/CD pipeline may call BitOps multiple times if it requires one environment to run as a pre-requisite for another.