update docs

Author: GrantBirki

README.md

@@ -309,6 +309,7 @@ As seen above, we have two steps. One for a noop deploy, and one for a regular d
 | `actor` | The GitHub handle of the actor that invoked the IssueOps command |
 | `environment` | The environment that has been selected for a deployment |
 | `params` | The raw parameters that were passed into the deployment command (see param_separator) - Further [documentation](docs/parameters.md) |
+| `parsed_params` | A stringified JSON object of the parsed parameters that were passed into the deployment command - Further [documentation](docs/parameters.md) |
 | `noop` | The string "true" if the noop trigger was found, otherwise the string "false" - Use this to conditionally control whether your deployment runs as a noop or not |
 | `sha` | The sha of the branch to be deployed |
 | `default_branch_tree_sha` | The sha of the default branch tree (useful for subsequent workflow steps if they need to do commit comparisons) |

docs/parameters.md

@@ -14,7 +14,10 @@ Here are a few examples of how to pass in parameters to the `.deploy` command an
 .deploy to development | LOG_LEVEL=debug,CPU_CORES=4
 ```
 
-**Outputs**: `params` = `LOG_LEVEL=debug,CPU_CORES=4`
+**Outputs**:
+
+- `params` = `LOG_LEVEL=debug,CPU_CORES=4`
+- `parsed_params` = `["LOG_LEVEL=debug,CPU_CORES=4"]`
 
 **Why**: A user might need to deploy to the development environment and tell subsequent workflow steps to use a `LOG_LEVEL` of `debug` and `CPU_CORES` of `4`.
 
@@ -26,10 +29,28 @@ Here are a few examples of how to pass in parameters to the `.deploy` command an
 .deploy | something1 something2 something3
 ```
 
-**Outputs**: `params` = `something1 something2 something3`
+**Outputs**:
+
+- `params` = `something1 something2 something3`
+- `parsed_params` = `["something1", "something2", "something3"]`
 
 **Why**: This example shows that the `params` output is just a string that can be literally anything your heart desires. It is up to the user to parse the string and use it in subsequent steps.
 
+### Example 3
+
+**Command**:
+
+```text
+.deploy | --cpu=2 --memory=4G --env=development --port=8080 --name=my-app -q my-queue
+```
+
+**Outputs**:
+
+- `params` = `--cpu=2 --memory=4G --env=development --port=8080 --name=my-app -q my-queue`
+- `parsed_params` = `{_: [], cpu: 2, memory: '4G', env: 'development', port: 8080, name: 'my-app', q: 'my-queue'}`
+
+**Why**: This example shows that by using structure within your params string like `--key=value`, they can be automatically parsed into a JSON object and saved as the `parsed_params` output. This can be useful for users that want to pass in a number of parameters to their deployment and have them automatically parsed and saved as a JSON object as an output of this Action. Having machine readable output can be quite useful for subsequent workflow steps.
+
 ## Parameter Separator
 
 The `param_separator` input defaults to `|` and will collect any text that is provided after this character and save it as a GitHub Actions output called `params`. This output can then be used in subsequent steps.
@@ -38,7 +59,7 @@ This value can be configured to be any character (or string) that you want.
 
 ## Parameter Output
 
-The `params` output can be accessed just like any other output from the `branch-deploy` Action. Here is a quick example:
+The `params` and `parsed_params` outputs can be accessed just like any other output from the `branch-deploy` Action. Here is a quick example:
 
 ```yaml
 - name: branch-deploy
@@ -52,4 +73,5 @@ The `params` output can be accessed just like any other output from the `branch-
   if: steps.branch-deploy.outputs.continue == 'true'
   run: |
     echo "params: ${{ steps.branch-deploy.outputs.params }}"
+    echo "parsed_params: ${{ steps.branch-deploy.outputs.parsed_params }}"
 ```