chore: fix typos

SUPPORT.md

@@ -10,7 +10,7 @@ For all questions documentation may not cover, we suggest utilizing [Github Disc
 All code issues should be a [Github Issue](https://github.com/defenseunicorns/zarf/issues/new/choose) that follows the issue template. 
 
 Following the templates provides the Zarf community a foundation of understanding to be able to assist quickly.
-After an issue is made, this issue can be brought into other chanels such as the [Kubernetes Slack #Zarf](https://zarf.dev/slack) channel or the [bi-weekly Zarf Community Meeting](https://docs.zarf.dev/contribute/contributor-guide/).
+After an issue is made, this issue can be brought into other channels such as the [Kubernetes Slack #Zarf](https://zarf.dev/slack) channel or the [bi-weekly Zarf Community Meeting](https://docs.zarf.dev/contribute/contributor-guide/).
 
                 Github Issue 
                 /          \

adr/0007-use-rust-binary-for-both-injection-stages.md

@@ -10,7 +10,7 @@ Amends [3. Image injection into remote clusters without native support](0003-ima
 
 ## Context
 
-In ADR 3, the decision was made to create a rust binary (`stage1`) that would re-assemble a `registry:2` image and a go registry binary (`stage2`) from a series of configmaps. While this solution works, it is overkill for the operations that `stage2` performs. The `stage2` binary is only responsible for 1. starting a docker registry in `rw` mode, 2. pushing the `registry:2` crane tarball into said registry, 3. starting the docker registry in `r` mode. This `registry:2` image is then immedietely consumed by the `zarf-registry` package, creating a true in-cluster docker registry. The injector pod is then destroyed. The overhead this operation creates:
+In ADR 3, the decision was made to create a rust binary (`stage1`) that would re-assemble a `registry:2` image and a go registry binary (`stage2`) from a series of configmaps. While this solution works, it is overkill for the operations that `stage2` performs. The `stage2` binary is only responsible for 1. starting a docker registry in `rw` mode, 2. pushing the `registry:2` crane tarball into said registry, 3. starting the docker registry in `r` mode. This `registry:2` image is then immediately consumed by the `zarf-registry` package, creating a true in-cluster docker registry. The injector pod is then destroyed. The overhead this operation creates:
 
 - having to keep track of another binary (making the total number 3 for the zarf ecosystem)
 - nearly doubling the amount of configmaps loaded into the cluster (makes init slower)

adr/0012-local-image-support-via-docker.md

@@ -21,7 +21,7 @@ We did extensive investigation into various strategies of loading docker images
 
 ## Decision
 
-We had hoped to leverage docker caching and avoid crane caching moreso, but realized that caching was still occurring via Syft for SBOM. Additionally, the extremely-large, local-only image is actually the edge case here and we created a recommended workaround in the FAQs as well as an inline alert when a large docker image is detected. This restores behavior to what it was before the docker daemon support was added, but with the added benefit of being able to load images from the docker daemon when they are available locally.
+We had hoped to leverage docker caching and avoid crane caching more, but realized that caching was still occurring via Syft for SBOM. Additionally, the extremely-large, local-only image is actually the edge case here and we created a recommended workaround in the FAQs as well as an inline alert when a large docker image is detected. This restores behavior to what it was before the docker daemon support was added, but with the added benefit of being able to load images from the docker daemon when they are available locally.
 
 ## Consequences
 

adr/0017-zarf-bundle.md

@@ -80,7 +80,7 @@ Cons:
 
 The current proposition (subject to change before acceptance) is **Zarf Bundles**, which a following PR will focus on and create a POC of.
 
-In essense the `zarf-bundle.yaml` would look something like so:
+In essence the `zarf-bundle.yaml` would look something like so:
 
 ```yaml
 metadata:

adr/0020-package-sources.md

@@ -70,7 +70,7 @@ The following sources have been implemented:
 - Published OCI package (`oci://`)
 - In-cluster (Deployed) package (`inspect` and `remove` only)
 
-The `layout` library contains the `PackagePaths` struct which supercedes the prior `TempPaths` struct. This new struct contains access methods to different aspects of Zarf's internal package layout. This struct is passed to the `PackageSource` functions to allow for the loading of packages into the correct layout. In order for a package to be loaded into the correct layout, the package must follow the default Zarf package structure, or be converted to the expected structure during loading operations.
+The `layout` library contains the `PackagePaths` struct which supersedes the prior `TempPaths` struct. This new struct contains access methods to different aspects of Zarf's internal package layout. This struct is passed to the `PackageSource` functions to allow for the loading of packages into the correct layout. In order for a package to be loaded into the correct layout, the package must follow the default Zarf package structure, or be converted to the expected structure during loading operations.
 
 ## Consequences
 

adr/0024-starlight.md

@@ -70,7 +70,7 @@ To simplify the development process and improve the performance of the documenta
 
 ## Consequences
 
-- During the transition, we will need to update the existing documentation content to work with the new site generator. Additionally, the site archictecture will be re-evaluated and optimized. This _will_ result in many links to current content breaking.
+- During the transition, we will need to update the existing documentation content to work with the new site generator. Additionally, the site architecture will be re-evaluated and optimized. This _will_ result in many links to current content breaking.
 - Every documentation generator has its quirks and limitations, so we will need to adapt to the new workflow and learn how to best utilize the features of Starlight.
 - The migration will take time and effort, but the benefits of improved performance and flexibility will be worth it in the long run.
 - The team will need to learn how to use Astro and Starlight, which may require some training and experimentation.

packages/zarf-registry/chart/templates/hpa.yaml

@@ -29,7 +29,7 @@ spec:
           averageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }}
   behavior:
     scaleDown:
-      # Use 60 second stabilization window becuase zarf will freeze scale down during deploys
+      # Use 60 second stabilization window because zarf will freeze scale down during deploys
       stabilizationWindowSeconds: 60
       # Initially disable scale down - this gets set to Min later by Zarf (src/test/e2e/20_zarf_init_test.go)
       selectPolicy: Disabled

src/cmd/tools/helm/root.go

@@ -235,7 +235,7 @@ func checkForExpiredRepos(repofile string) {
 	}
 
 	// parse repo file.
-	// Ignore the error because it is okay for a repo file to be unparseable at this
+	// Ignore the error because it is okay for a repo file to be unparsable at this
 	// stage. Later checks will trap the error and respond accordingly.
 	repoFile, err := repo.LoadFile(repofile)
 	if err != nil {

src/pkg/cluster/tunnel_test.go

@@ -40,7 +40,7 @@ func TestServiceInfoFromNodePortURL(t *testing.T) {
 			expectedErr: "no matching node port services found",
 		},
 		{
-			name:        "found serivce",
+			name:        "found service",
 			nodePortURL: "http://localhost:30001",
 			services: []corev1.Service{
 				{

src/pkg/message/handler.go

@@ -17,7 +17,7 @@ func (z ZarfHandler) Enabled(_ context.Context, _ slog.Level) bool {
 	return true
 }
 
-// WithAttrs is not suppported
+// WithAttrs is not supported
 func (z ZarfHandler) WithAttrs(_ []slog.Attr) slog.Handler {
 	return z
 }