wip: markdown and spelling fixes

.config/dictionaries/project.dic

@@ -10,6 +10,7 @@ Earthfiles
 errchkjson
 extldflags
 ginkgolinter
+gitops
 glightbox
 gofmt
 golangci
@@ -37,6 +38,7 @@ nixos
 nixpkgs
 onsi
 pkgs
+projectcatalyst
 pymdownx
 PYTHONDONTWRITEBYTECODE
 rivo

docs/src/onboarding/actions.md

@@ -1,24 +1,26 @@
 # GitHub Actions
 
+<!-- markdownlint-disable max-one-sentence-per-line -->
 !!! Note
-    If you don't intend on using the custom GitHub Actions to build custom workflows, you're encouraged to skip this section and move on
-    to the next one.
+    If you don't intend on using the custom GitHub Actions to build custom workflows, you're encouraged to skip this section and
+    move on to the next one.
     However, understanding how the individual actions work, and the role they play, can greatly help when troubleshooting workflows.
 
 Catalyst CI is made up of several GitHub Actions that simplify the steps required to perform the CI process.
 All of these GitHub Actions are compiled into reusable workflows which perform a majority of the CI logic.
+<!-- markdownlint-enable max-one-sentence-per-line -->
 
 ## Overview
 
 The following actions are provided by Catalyst CI:
 
-- [configure-runner](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/configure-runner)
-- [discover](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/discover)
-- [install](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/install)
-- [merge](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/merge)
-- [push](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/push)
-- [run](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/run)
-- [setup](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/setup)
+* [configure-runner](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/configure-runner)
+* [discover](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/discover)
+* [install](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/install)
+* [merge](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/merge)
+* [push](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/push)
+* [run](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/run)
+* [setup](https://github.com/input-output-hk/catalyst-ci/tree/master/actions/setup)
 
 This section will only highlight the actions which are commonly used in most workflows.
 Additionally, we will not cover these actions in depth.
@@ -32,11 +34,11 @@ The `setup` action is by far the most common action and shows up in a majority o
 It performs the necessary steps to setup the local GitHub runner to perform CI tasks.
 This includes:
 
-- Installing Earthly
-- Installing the custom CI CLI
-- Configuring access to AWS
-- Authenticating with container registries
-- Configuring the Earthly remote runner
+* Installing Earthly
+* Installing the custom CI CLI
+* Configuring access to AWS
+* Authenticating with container registries
+* Configuring the Earthly remote runner
 
 Most of these steps are configurable and can be individually disabled.
 When creating custom workflows, it's highly recommended to use this action to perform common set up tasks.
@@ -66,4 +68,4 @@ A custom action was created to perform this task for the following reasons:
 When creating custom workflows, it's highly recommended to use this action when calling Earthly for the above reasons.
 If the action does not support the invocation you need, it's better to modify the action rather than manually execute the `earthly`
 CLI.
-The only exception to this rule is when the invocation is unlikely to be used in more than one place.
+The only exception to this rule is when the invocation is unlikely to be used in more than one place.

docs/src/onboarding/targets.md

@@ -1,7 +1,7 @@
 # Targets
 
 As discussed in the overview, the Catalyst CI automatically searches for and executes distinct Earthly targets.
-By creating these targets in your `Earthfile`, you can hook into the Cataly CI process with minimal effort.
+By creating these targets in your `Earthfile`, you can hook into the Catalyst CI process with minimal effort.
 This section is dedicated to explaining what these targets are, how they work, and how to use them.
 
 ## Check
@@ -83,7 +83,7 @@ This allows end-users to validate that their release artifacts build as expected
 If instead the commit contains a git tag, then the resulting artifacts are compressed into a single tarball and uploaded as an
 artifact of the GitHub Action job.
 The compression happens regardless of whether a single or multiple artifacts were produced.
-After the `release` target has been run for _every_ subproject, the produced artifacts from all subprojects are then attached into a
+After the `release` target has been run for *every* subproject, the produced artifacts from all subprojects are then attached into a
 single GitHub release for the given git tag (i.e., `1.0.0`).
 
 ### Usage
@@ -97,4 +97,4 @@ Artifacts should have some relevance for a GitHub release.
 For example, making the target save the local source code is redundant since GitHub automatically includes all source code when a
 new release is created.
 However, a consumer may want to be able to download precompiled versions of a binary (without relying on a container).
-In this case, it makes sense to create a release target that produces the binary as an artifact.
+In this case, it makes sense to create a release target that produces the binary as an artifact.

docs/src/onboarding/udc.md

@@ -11,7 +11,7 @@ UDCs are helpful for several reasons:
 2. They can encapsulate complex logic into a simple contractual interface
 3. They enforce standardization and prevent solving the same problem in multiple different ways
 
-The third reason is particulary useful for Catalyst as we have multiple repositories with dozens of Earthfiles often solving similar
+The third reason is particularly useful for Catalyst as we have multiple repositories with dozens of Earthfiles often solving similar
 problems.
 
 ## Usage
@@ -34,4 +34,4 @@ Please feel encouraged to contribute UDCs to the repository.
 If you're seeing the same logic being re-used across multiple Earthfiles in a repository, this is a good candidate for refactoring
 into a UDC.
 Additionally, for SMEs who are aware of language best practices, encoding those into a UDC will help increase the overall health of
-the CI process.
+the CI process.

docs/src/onboarding/workflows.md

@@ -4,15 +4,15 @@ The Catalyst CI process works by combining several high-level reusable workflows
 our repositories.
 The purpose for this is to standardize the CI process across all repositories as well as provide control for easily updating the CI
 process without having to make changes across multiple repositories.
-This section gives a brief overview of these reusable workflows, which can aid in troubelshooting purposes.
+This section gives a brief overview of these reusable workflows, which can aid in troubleshooting purposes.
 
 ## Overview
 
 Most reusable workflows have a one-to-one relationship with the Earthly targets discussed in the previous section:
 
-- `check.yml` is responsible for handling the `check` target
-- `publish.yml` is responsible for handling the `publish` target
-- `release.yml` is responsible for hanlding the `release` target
+* `check.yml` is responsible for handling the `check` target
+* `publish.yml` is responsible for handling the `publish` target
+* `release.yml` is responsible for handling the `release` target
 
 Each workflow is self-contained and independent of the other workflows.
 However, in most cases, they are tied together with conditionals (i.e. `publish` only runs if `check` succeeds).
@@ -37,7 +37,7 @@ As noted above, Catalyst CI uses a remote Earthly runner in order to maximize ca
 As a result, all workflows that interact with Earthly will accept optional inputs describing the address of the runner as well as
 the name of an AWS secret containing the authentication details.
 The workflow will configure the local GitHub runner using the TLS credentials retrieved from AWS so that it can successfully connect
-and interact with the rexmote Earthly runner.
+and interact with the remote Earthly runner.
 
 ## Check
 
@@ -67,7 +67,7 @@ If the target returns a non-zero exit code it will bubble up and cause the job t
 
 The publish workflow is responsible for performing the logic related to the `publish` target.
 It uses the custom `run` GitHub Action to execute the target and parse the name/tag of the resulting image.
-It then uses the custom `push` GitHub Action to retag the image and push it to the appropriate image registries.
+It then uses the custom `push` GitHub Action to re-tag the image and push it to the appropriate image registries.
 
 ### Inputs
 
@@ -92,7 +92,7 @@ It then uses the custom `push` GitHub Action to retag the image and push it to t
 
 The release workflow is responsible for performing logic related to the `release` target.
 It uses the custom `run` GitHub Action to execute the target and store the produced artifacts to a local directory on the runner.
-These arifacts are then compressed and ultimately uploaded as artifacts for the job and/or a new GitHub release.
+These artifacts are then compressed and ultimately uploaded as artifacts for the job and/or a new GitHub release.
 
 ### Inputs
 
@@ -125,11 +125,11 @@ The changes are then committed, causing the `dev` environment to deploy the newl
 | --------------- | ------ | ---------------------------------------------------- | -------- | -------------------------------- |
 | deployment_repo | string | The URL of the repository containing deployment code | No       | `input-output-hk/catalyst-world` |
 | environment     | string | The target environment to deploy to                  | No       | `dev`                            |
-| images          | string | A newline separated list of image names to deplo     | Yes      | N/A                              |
+| images          | string | A newline separated list of image names to deploy    | Yes      | N/A                              |
 | tag             | string | The image tag to deploy                              | Yes      | N/A                              |
 
 ### Secrets
 
 | Name  | Type   | Description                                              | Required | Default |
 | ----- | ------ | -------------------------------------------------------- | -------- | ------- |
-| token | string | A Github token with access to the deployment repository. | Yes      | N/A     |
+| token | string | A Github token with access to the deployment repository. | Yes      | N/A     |