Docs edits to "Component Actions" page

docs/4-user-guide/5-component-actions.md

@@ -1,25 +1,25 @@
 # Component Actions
 
-Component Actions provide a number of exec entrypoints for a component to perform additional logic during key stages of a component's lifecycle. These actions will be executed with the context that the Zarf binary is executed with. See [Zarf Package Lifecycle](4-package-command-lifecycle.md) for details on the execution sequence of component actions. You can also try out the component actions example [here](../../examples/component-actions/README.md).
+Component Actions offer several exec entrypoints that allow a component to perform additional logic at key stages of its lifecycle. These actions are executed within the same context as the Zarf binary. For a detailed overview of the execution sequence of component actions, please refer to the [Zarf Package Lifecycle](4-package-command-lifecycle.md) documentation. Additionally, you can experiment with the component actions example located in the [Component Actions](../../examples/component-actions/README.md) example page.
 
 ## Action Sets
 
-`component.actions` contain the following (optional) keys known as `action sets`:
+The `component.actions` field includes the following optional keys, also known as `action sets`:
 
-- `onCreate` - Runs during `zarf package create`
-- `onDeploy` - Runs during `zarf package deploy`
-- `onRemove` - Runs during `zarf package remove`
+- `onCreate` - Runs during `zarf package create`.
+- `onDeploy` - Runs during `zarf package deploy`.
+- `onRemove` - Runs during `zarf package remove`.
 
 ## Action Lists
 
-These `action sets` contain (optional) `action` lists. The `onSuccess` and `onFailure` action lists are conditional and depend on the success or failure of previous actions in the same component as well as steps in the component lifecycle.
+These `action sets` contain optional `action` lists. The `onSuccess` and `onFailure` action lists are conditional and rely on the success or failure of previous actions within the same component, as well as the component's lifecycle stages.
 
-- `before` - sequential list of actions that will run before this component is processed for `create`, `deploy`, or `remove`
-- `after` - sequential list of actions that will run after this component is successfully processed for `create`, `deploy`, or `remove`
-- `onSuccess` - sequential list of actions that will run after **ALL** `after` actions have successfully completed
-- `onFailure` - sequential list of actions that will run after **ANY** error during the above actions or component operations
+- `before` - sequential list of actions that will run before this component is processed for `create`, `deploy`, or `remove`.
+- `after` - sequential list of actions that will run after this component is successfully processed for `create`, `deploy`, or `remove`.
+- `onSuccess` - sequential list of actions that will run after **ALL** `after` actions have successfully completed.
+- `onFailure` - sequential list of actions that will run after **ANY** error during the above actions or component operations.
 
-Below are some examples of `action` lists and their usage:
+Below are some examples of `action` lists and their usages:
 
 ```yaml
 components:
@@ -83,7 +83,7 @@ components:
 
 ## Action Set Defaults
 
-In addition to the `action` lists above, an `action set` also contains a `defaults` section that will be applied to all actions in the set. The `defaults` section contains all of the same elements as an [action configuration](#action-configuration), except for `cmd` which is not allowed in the `defaults` section. Example:
+In addition to the `action` lists above, an `action set` also contains a `defaults` section that will be applied to all actions in the set. The `defaults` section contains all of the same elements as an action configuration, with the exception of the `cmd` element, which is not allowed in the `defaults` section. Below is an example of `action set` defaults: 
 
 ```yaml
 actions:
@@ -110,46 +110,50 @@ actions:
 
 The following keys are common to all action configurations (wait or command):
 
-- `description` - a description of the action that will replace the text the user sees when the action is running, e.g. `description: "File to be created"` would show `Waiting for "File to be created"` instead of `Waiting for "touch test-create-before.txt"`
-- `maxTotalSeconds` - the maximum total time to allow the command to run (default: `0` - no limit for command actions, `300` - 5 minutes for wait actions)
+- `description` - a description of the action that will replace the default text displayed to the user when the action is running. For example: `description: "File to be created"` would display `Waiting for "File to be created"` instead of `Waiting for "touch test-create-before.txt"`.
+- `maxTotalSeconds` - the maximum total time to allow the command to run (default: `0` - no limit for command actions, `300` - 5 minutes for wait actions).
 
 ## Command Action Configuration
 
-A command action executes arbitrary commands or scripts in a shell wrapper. Use the `cmd` key to define the command(s) to run. This can also be a multi-line script. _You cannot use `cmd` and `wait` in the same action_. Within each of the `action` lists (`before`, `after`, `onSuccess`, and `onFailure`), the following action configurations are available:
+A command action executes arbitrary commands or scripts within a shell wrapper. You can use the `cmd` key to define the command(s) to run. This can also be a multi-line script. _You cannot use `cmd` and `wait` in the same action_. 
 
-- `cmd` - (required if not a wait action) the command to run
-- `dir` - the directory to run the command in, defaults to the current working directory
-- `mute` - whether to mute the realtime output of the command, output is always shown at the end on failure (default: `false`)
-- `maxRetries` - the maximum number of times to retry the command if it fails (default: `0` - no retries)
-- `env` - an array of environment variables to set for the command in the form of `name=value`
-- `setVariables` - set the standard output of the command to a list of variables that can be used in other actions or components (onDeploy only)
+Within each of the `action` lists (`before`, `after`, `onSuccess`, and `onFailure`), the following action configurations are available:
+
+- `cmd` - (required if not a wait action) the command to run.
+- `dir` - the directory to run the command in, defaults to the current working directory.
+- `mute` - whether to mute the realtime output of the command, output is always shown at the end on failure (default: `false`).
+- `maxRetries` - the maximum number of times to retry the command if it fails (default: `0` - no retries).
+- `env` - an array of environment variables to set for the command in the form of `name=value`.
+- `setVariables` - set the standard output of the command to a list of variables that can be used in other actions or components (onDeploy only).
 
 ## Wait Action Configuration
 
-A wait action pauses the component stage it is triggered in until the condition is met, or triggers a failure if maxTotalSeconds is exceeded (defaults to 5 minutes). Use the `wait` key to define the wait parameters, _you cannot use `cmd` and `wait` in the same action_. A wait action is really just _yaml sugar_ for a call to `./zarf tools wait-for`, but in a more exciting yaml-sort-of-way. Within each of the `action` lists (`before`, `after`, `onSuccess`, and `onFailure`), the following action configurations are available:
+The `wait` action temporarily halts the component stage it's initiated in, either until the specified condition is satisfied or until the maxTotalSeconds time limit is exceeded (which, by default, is set to 5 minutes). To define `wait` parameters, execute the `wait` key; it's essential to note that _you cannot use `cmd` and `wait` in the same action_. Essentially, a `wait` action is _yaml sugar_ for a call to `./zarf tools wait-for`.
+
+Within each of the `action` lists (`before`, `after`, `onSuccess`, and `onFailure`), the following action configurations are available:
 
-- `wait` - (required if not a cmd action) the wait parameters
-  - `cluster` - perform a wait operation on a Kubernetes resource (kubectl wait)
-    - `kind` - the kind of resource to wait for (required)
-    - `identifier` - the identifier of the resource to wait for (required), can be a name or label selector
-    - `namespace` - the namespace of the resource to wait for
-    - `condition` - the condition to wait for (default: `exists`)
-  - `network` - perform a wait operation on a network resource (curl)
-    - `protocol` - the protocol to use (i.e. `http`, `https`, `tcp`)
-    - `address` - the address/port to wait for (required)
-    - `code` - the HTTP status code to wait for if using `http` or `https`, or `success` to check for any 2xx response code (default: `success`)
+- `wait` - (required if not a cmd action) the wait parameters.
+  - `cluster` - perform a wait operation on a Kubernetes resource (kubectl wait).
+    - `kind` - the kind of resource to wait for (required).
+    - `identifier` - the identifier of the resource to wait for (required), can be a name or label selector.
+    - `namespace` - the namespace of the resource to wait for.
+    - `condition` - the condition to wait for (default: `exists`).
+  - `network` - perform a wait operation on a network resource (curl).
+    - `protocol` - the protocol to use (i.e. `http`, `https`, `tcp`).
+    - `address` - the address/port to wait for (required).
+    - `code` - the HTTP status code to wait for if using `http` or `https`, or `success` to check for any 2xx response code (default: `success`).
 
 ---
 
-## Creating dynamic variables from actions
+## Creating Dynamic Variables from Actions
 
-You can use the `setVariables` action configuration to set a list of variables that can be used in other actions or components during `zarf package deploy`. The variable will be set in the environment variable `ZARF_VAR_{NAME}` and `TF_VAR_{name}` in the remaining actions as well as available for templating in files or manifests in the remaining components as `###ZARF_VAR_{NAME}###`. This feature allows package authors to define dynamic runtime variables for consumption by other components or actions. _Unlike normal variables, these do not need to be defined at the top of the `zarf.yaml`._
+You can use the `setVariables` action configuration to set a list of variables that can be used in other actions or components during `zarf package deploy`. The variable will be assigned values in two environment variables: `ZARF_VAR_{NAME}` and `TF_VAR_{name}`. These values will be accessible in subsequent actions and can be used for templating in files or manifests in other components as `###ZARF_VAR_{NAME}###`. This feature allows package authors to define dynamic runtime variables for consumption by other components or actions. _Unlike normal variables, these do not need to be defined at the top of the `zarf.yaml`._
 
-## More examples
+## Additional Action Examples
 
 ### `onCreate`
 
-`onCreate` runs during `zarf package create` and allows a package creator to run commands during package creation. For example if you have a large data file that you need to include in your package you could include something like the following (replacing the url as needed):
+The `onCreate` action runs during `zarf package create` and allows a package creator to run commands during package creation. For instance, if a large data file must be included in your package, the following example (with the URL updated accordingly) can be used:
 
 ```yaml
 components:
@@ -162,9 +166,9 @@ components:
 
 ### `onDeploy.before`
 
-`onDeploy` runs during `zarf package deploy` and allow a package to execute commands during component deployment.
+The `onDeploy` action runs during `zarf package deploy` and allow a package to execute commands during component deployment.
 
-You can use `onDeploy.before` to execute a command _before_ the component is deployed. This example uses the `eksctl` binary to create an EKS cluster. The `eks.yaml` file is included in the package and contains the configuration for the cluster:
+You can use `onDeploy.before` to execute a command _before_ the component is deployed. The following example uses the `eksctl` binary to create an EKS cluster. The package includes the `eks.yaml` file, which contains the cluster configuration:  
 
 ```yaml
 components:
@@ -177,7 +181,7 @@ components:
 
 ### `onDeploy.after`
 
-You can also use `onDeploy.after` to execute a command _after_ the component is deployed. For example if you need to cleanup resources that were temporarily created during deployment:
+The `onDeploy.after` can be used to execute a command _after_ the component is deployed. This can be useful for resource cleanup of any temporary resources created during the deployment process:
 
 ```yaml
 components:
@@ -190,7 +194,7 @@ components:
 
 ### `onRemove`
 
-`onRemove` runs during `zarf package remove` and allows a package to execute commands during component removal.
+The `onRemove` action runs during `zarf package remove` and allows a package to execute commands during component removal.
 
 :::note