zarf-dev · jeff-mccoy · Jul 26, 2022 · Jul 23, 2022
diff --git a/adr/0002-moving-e2e-tests-away-from-terratest.md b/adr/0002-moving-e2e-tests-away-from-terratest.md
@@ -29,7 +29,7 @@ When looking back at the list of 'important additions' we were considering above
 
 ## Consequences
 
-While it was not something we were doing before, testing directly on the GitHub Runner instead of using Terratest to test on an ec2 instance means that when we get around to adding automated testing of Zarf against different linux distrobutions we will want to have more discussions on if we want to use self-hosted runners of different OS's or if we want to go back to Terratest to stand up ec2 instances with different AMIs.
+While it was not something we were doing before, testing directly on the GitHub Runner instead of using Terratest to test on an ec2 instance means that when we get around to adding automated testing of Zarf against different linux distributions we will want to have more discussions on if we want to use self-hosted runners of different OS's or if we want to go back to Terratest to stand up ec2 instances with different AMIs.
 
 In the future, we will likely want to write E2E tests that use images that require repository secrets to access. When that happens we will want to bring back some form of 'maintainer action' to initiate the test workflow. Going back to [peter-evans/slash-command-dispatch@v2](https://github.com/peter-evans/slash-command-dispatch) might be the right answer for that but there will need to be more discussion to make sure the team agrees that's the best solution first.
 

diff --git a/adr/0004-generate-sboms-with-witness.md b/adr/0004-generate-sboms-with-witness.md
@@ -16,4 +16,4 @@ Using Witness' Syft attestor functionality allows Zarf to continue to get more r
 
 ## Consequences
 
-Added depenencies of Witness and Syft which may inflate Zarf binary size.  Increased Zarf package size -- Jeff noted that uncompressed SBOMs for Big Bang Core came in at around 200MB.
+Added dependencies of Witness and Syft which may inflate Zarf binary size.  Increased Zarf package size -- Jeff noted that uncompressed SBOMs for Big Bang Core came in at around 200MB.
diff --git a/adr/0005-mutating-webhook.md b/adr/0005-mutating-webhook.md
@@ -12,7 +12,7 @@ Currently Zarf leverages [Helm Post Rendering](https://helm.sh/docs/topics/advan
 
 ## Decision
 
-A [mutating webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) is standard practice in K8s and there [are a lot of them](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do). Using the normal Zarf componenet structure and deployment strategy we can leverage a mutating webhook to perform automatic imagePullSecret binding and image path updates as well as add additional as-needed mutations such as updating the [GitRepository](https://fluxcd.io/docs/components/source/gitrepositories/) CRD with the appropriate secret and custom URL for the git server if someone is using Flux.
+A [mutating webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/) is standard practice in K8s and there [are a lot of them](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do). Using the normal Zarf component structure and deployment strategy we can leverage a mutating webhook to perform automatic imagePullSecret binding and image path updates as well as add additional as-needed mutations such as updating the [GitRepository](https://fluxcd.io/docs/components/source/gitrepositories/) CRD with the appropriate secret and custom URL for the git server if someone is using Flux.
 
 ## Consequences
 

diff --git a/docs/12-support.md b/docs/12-support.md
@@ -3,4 +3,4 @@
 1. Make sure you've read the [Zarf Overview](./0-zarf-overview.md), [Understanding the Basics](./1-understand-the-basics.md), and the [Getting Started](./3-getting-started.md) guides. 
 2. Look for an answer in [the frequently asked questions](./9-faq.md).
 3. Ask a question in [the Zarf Slack Channel](https://kubernetes.slack.com/archives/C03B6BJAUJ3)
-4. [Read issues, report a bug, or rquest a new feature](https://github.com/defenseunicorns/zarf/issues)
+4. [Read issues, report a bug, or request a new feature](https://github.com/defenseunicorns/zarf/issues)
diff --git a/docs/13-walkthroughs/0-creating-a-zarf-package.md b/docs/13-walkthroughs/0-creating-a-zarf-package.md
@@ -6,7 +6,7 @@ In this walkthrough we will be demonstrating how to build a Zarf package. In fac
 When creating a Zarf package, you will need to have internet connection out so that Zarf can fetch all the dependencies and resources necessary to build the package. If your package is using images from a private registry or is referencing repositories in a private repository, you will need to have your credentials configured on your machine in order for Zarf to be able to fetch the resources.
 
 
-## Walkthrough Prequisites
+## Walkthrough Prerequisites
 1. The [Zarf](https://github.com/defenseunicorns/zarf) repository cloned: ([git clone instructions](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository))
 2. Zarf binary installed on your $PATH: ([install instructions](../3-getting-started.md#installing-zarf))
 3. A copy of the injector's `zarf-registry` binary in the `build/` directory: ([build instructions](../3-getting-started.md#building-the-cli-from-scratch))

diff --git a/docs/13-walkthroughs/1-initializing-a-k8s-cluster.md b/docs/13-walkthroughs/1-initializing-a-k8s-cluster.md
@@ -3,7 +3,7 @@
 Before you're able to deploy an application package to a cluster, you need to initialize the cluster. This is done by running the [`zarf init`](../4-user-guide/1-the-zarf-cli/100-cli-commands/zarf_init.md) command. The `zarf init` command uses a specialized package that we have been calling an 'init-package'. More information about this specific package can be found [here](../4-user-guide/2-zarf-packages/3-the-zarf-init-package.md).
 
 
-## Walkthrough Prequisites
+## Walkthrough Prerequisites
 1. The [Zarf](https://github.com/defenseunicorns/zarf) repository cloned: ([`git clone` Instructions](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository))
 1. Zarf binary installed on your $PATH: ([Install Instructions](../3-getting-started.md#installing-zarf))
 1. An init-package built/downloaded: ([init-package Build Instructions](./0-creating-a-zarf-package.md)) or ([Download Location](https://github.com/defenseunicorns/zarf/releases))

diff --git a/docs/13-walkthroughs/2-deploying-doom.md b/docs/13-walkthroughs/2-deploying-doom.md
@@ -3,7 +3,7 @@
 In this walkthrough, we are going to deploy a fun application onto your cluster. In some of the previous walkthroughs, we have figured out how to [create a package](./0-creating-a-zarf-package.md) and [initialize a cluster](./1-initializing-a-k8s-cluster.md). We will be leveraging all that past work and then go the extra step of deploying an application onto our cluster with the `zarf package deploy` command. While this example game is nothing crazy, this walkthrough hopes to show how simple it is to deploy packages of functionality into a Kubernetes cluster.
 
 
-## Walkthrough Prequisites
+## Walkthrough Prerequisites
 1. The [Zarf](https://github.com/defenseunicorns/zarf) repository cloned: ([`git clone` Instructions](https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository))
 1. Zarf binary installed on your $PATH: ([Install Instructions](../3-getting-started.md#installing-zarf))
 1. A Kubernetes cluster that has been initialized by Zarf: ([Initializing a Cluster Instructions](./1-initializing-a-k8s-cluster.md))

diff --git a/docs/4-user-guide/1-the-zarf-cli/100-cli-commands/zarf_destroy.md b/docs/4-user-guide/1-the-zarf-cli/100-cli-commands/zarf_destroy.md
@@ -8,7 +8,7 @@ Tear down Zarf.
 
 Deletes everything in the 'zarf' namespace within your connected k8s cluster.
 
-If Zarf deployed your k8s cluster, this command will also tear your cluster down bysearching through /opt/zarf for any scripts that start with 'zarf-clean-' and executing them. Since this is a cleanup operation, Zarf will not stop the teardown if one of the scripts produce an error.
+If Zarf deployed your k8s cluster, this command will also tear your cluster down by searching through /opt/zarf for any scripts that start with 'zarf-clean-' and executing them. Since this is a cleanup operation, Zarf will not stop the teardown if one of the scripts produce an error.
 
 If Zarf did not deploy your k8s cluster, this command will delete the Zarf namespace, delete secrets and labels that only Zarf cares about, and optionally uninstall components that Zarf deployed onto the cluster. Since this is a cleanup operation, Zarf will not stop the uninstalls if one of the resources produce an error while being deleted.
 

diff --git a/docs/4-user-guide/2-zarf-packages/2-zarf-components.md b/docs/4-user-guide/2-zarf-packages/2-zarf-components.md
@@ -4,7 +4,7 @@ sidebar_position: 2
 
 # Understanding Zarf Components
 
-The actual capabilities that Zarf Packages provided are defined within named components. These components define what dependencies they have and a declaritive definition of how it should be deployed. Each package can have as many components as the package creator wants but a package really isn't anything without at least one component.
+The actual capabilities that Zarf Packages provided are defined within named components. These components define what dependencies they have and a declarative definition of how it should be deployed. Each package can have as many components as the package creator wants but a package really isn't anything without at least one component.
 
 Components can define a wide range of resources that it needs when the package it is a part of gets deployed. The schema for the components is linked below but a high level look at the things components can define include:
  * Files to move onto the host

diff --git a/docs/4-user-guide/2-zarf-packages/3-the-zarf-init-package.md b/docs/4-user-guide/2-zarf-packages/3-the-zarf-init-package.md
@@ -41,7 +41,7 @@ There are two ways to deploy optional components, you can either pass a comma se
 
 Deploying onto air-gapped environments is a [hard problem](../../1-understand-the-basics.md#what-is-the-air-gap), especially when the k8s environment you're deploying to doesn't have a container registry running for you to put your images into. This leads to a classic 'chicken or the egg' problem since the container registry image needs to make its way into the cluster but there is on container registry running on the cluster to push to yet because the image isn't in the cluster yet. In order to remain distro agnostic, we had to come up with a unique solution to seed the container registry into the cluster.
 
-The `zarf-injector` [component](https://github.com/defenseunicorns/zarf/blob/master/packages/zarf-injector/zarf.yaml) within the init-package solves this problem by injecting a really small [Go registry binary](https://github.com/defenseunicorns/zarf/blob/master/src/injector/stage2/registry.go) into the cluster by splitting the binary into small enough chunks that would fit inside of a k8s ConfigMap. Once th config map is pushed onto the cluster, it gets stitched back together and runs to bootstrap the registry.
+The `zarf-injector` [component](https://github.com/defenseunicorns/zarf/blob/master/packages/zarf-injector/zarf.yaml) within the init-package solves this problem by injecting a really small [Go registry binary](https://github.com/defenseunicorns/zarf/blob/master/src/injector/stage2/registry.go) into the cluster by splitting the binary into small enough chunks that would fit inside of a k8s ConfigMap. Once the config map is pushed onto the cluster, it gets stitched back together and runs to bootstrap the registry.
 
 <!-- TODO: Fix this link.. -->
 More details about how we solved that problem is described in the [Seeding the Zarf Registry page](https://google.com).
diff --git a/docs/4-user-guide/index.md b/docs/4-user-guide/index.md
@@ -13,7 +13,7 @@ This guide is intended for end users who are using Zarf in a disconnected enviro
 
 ## Other Resources
 
-If you are looking for more advanced information on how to operate and custom configure Zarf to your specfic environment needs, check out these additional resources.
+If you are looking for more advanced information on how to operate and custom configure Zarf to your specific environment needs, check out these additional resources.
 
 - For information on how to create custom configuration of the Zarf CLI see the [Operator Manual](./../5-operator-manual/_category_.json)
 - For information on how to create your own custom Zarf Packages see the [Developer Guide](./../6-developer-guide/1-contributor-guide.md)

diff --git a/src/test/e2e/00_use_cli_test.go b/src/test/e2e/00_use_cli_test.go
@@ -55,7 +55,7 @@ func TestUseCLI(t *testing.T) {
 	assert.NotEqual(t, len(stdOut), 0, "Zarf version should not be an empty string")
 	assert.NotEqual(t, stdOut, "UnknownVersion", "Zarf version should not be the default value")
 
-	// Test for expected failure when given a bad componenet input
+	// Test for expected failure when given a bad component input
 	_, _, err = e2e.execZarfCommand("init", "--confirm", "--components=k3s,foo,logging")
 	assert.Error(t, err)
Original file line number	Diff line number	Diff line change
Expand Up		@@ -16,4 +16,4 @@ Using Witness' Syft attestor functionality allows Zarf to continue to get more r

		## Consequences

		Added depenencies of Witness and Syft which may inflate Zarf binary size. Increased Zarf package size -- Jeff noted that uncompressed SBOMs for Big Bang Core came in at around 200MB.
		Added dependencies of Witness and Syft which may inflate Zarf binary size. Increased Zarf package size -- Jeff noted that uncompressed SBOMs for Big Bang Core came in at around 200MB.