.noop docs updates

Author: GrantBirki

CONTRIBUTING.md

@@ -40,7 +40,7 @@ You can test your changes by doing the following steps:
 
 1. Commit your changes to the `main` branch on your fork
 2. Open a new pull request
-3. Run IssueOps commands on the pull request you just opened (`.deploy`, `.deploy noop`, `.deploy main`)
+3. Run IssueOps commands on the pull request you just opened (`.deploy`, `.noop`, `.deploy main`, etc)
 4. Ensure that all IssueOps commands work as expected on your testing PR
 
 ### Testing FAQs 🤔

README.md

@@ -18,7 +18,7 @@ This Action does the heavy lifting for you to enable branch deployments:
 ## Available Commands 💬
 
 - `.deploy` - Deploy a pull request
-- `.deploy noop` - Deploy a pull request in noop mode
+- `.noop` - Deploy a pull request in noop mode
 - `.deploy to <environment>` - Deploy a pull request to a specific environment
 - `.deploy <stable_branch>` - Trigger a rollback deploy to your stable branch (main, master, etc)
 - `.lock` - Create a deployment lock for the default environment
@@ -247,7 +247,7 @@ As seen above, we have two steps. One for a noop deploy, and one for a regular d
 - `steps.branch-deploy.outputs.continue == 'true'` - The `continue` variable is only set to true when a deployment should continue
 - `steps.branch-deploy.outputs.noop == 'true'` - The `noop` variable is only set to true when a noop deployment should be run
 
-> Example: You comment `.deploy noop` on a pull request. A noop deployment is detected so this action outputs the `noop` variable to `true`. You also have the correct permissions to execute the IssueOps command so the action also outputs the `continue` variable to `true`. This will allow the "fake noop deploy" step seen above to run and the "fake regular deploy" step will be skipped
+> Example: You comment `.noop` on a pull request. A noop deployment is detected so this action outputs the `noop` variable to `true`. You also have the correct permissions to execute the IssueOps command so the action also outputs the `continue` variable to `true`. This will allow the "fake noop deploy" step seen above to run and the "fake regular deploy" step will be skipped
 
 ## Inputs 📥
 
@@ -382,9 +382,9 @@ To use a deployment with a specific environment, you would invoke your commands
 
 This also works with noop commands as well
 
-- `.deploy noop production`
-- `.deploy noop to production`
-- `.deploy noop to <environment>`
+- `.noop production`
+- `.noop to production`
+- `.noop to <environment>`
 
 YAML input example:
 
@@ -571,7 +571,7 @@ This section will cover a few suggestions that will help you when using this Act
 
 Here are a few alternate ways you can invoke commands:
 
-- `.deploy noop staging` - Invoke a "noop" deployment to the staging environment
+- `.noop staging` - Invoke a "noop" deployment to the staging environment
 - `.deploy development` - Invoke a deployment to the development environment (notice how you can omit the "to" keyword)
 - `.deploy to development` - Invoke a deployment to the development environment (with the "to" keyword)
 - `.deploy` - Uses the default environment (usually "production")

docs/examples.md

@@ -25,7 +25,7 @@ Quick links below to jump to a specific branch-deploy example:
 
 This is the simplest possible example of how you could use the branch-deploy Action for reference
 
-- `.deploy noop` has no effect here (but you could change that)
+- `.noop` has no effect here (but you could change that)
 - `.deploy` will deploy the current branch (you can configure deployments however you like, this is just an example)
 
 ```yaml
@@ -70,7 +70,7 @@ jobs:
 
 This example shows how you could use this Action with [Terraform](https://www.terraform.io/)
 
-- `.deploy noop` triggers a Terraform plan
+- `.noop` triggers a Terraform plan
 - `.deploy` triggers a Terraform apply
 
 All deployment results get posted as a comment in the branch deploy output on your pull request
@@ -131,7 +131,7 @@ jobs:
         if: steps.branch-deploy.outputs.continue == 'true'
         run: terraform init
 
-        # If '.deploy noop' was used, run a Terraform plan
+        # If '.noop' was used, run a Terraform plan
       - name: Terraform plan
         if: ${{ steps.branch-deploy.outputs.continue == 'true' && steps.branch-deploy.outputs.noop == 'true' }}
         id: plan
@@ -178,7 +178,7 @@ jobs:
 
 This example shows how you could use this Action with [Heroku](https://heroku.com)
 
-- `.deploy noop` has no effect here (but you could change that)
+- `.noop` has no effect here (but you could change that)
 - `.deploy` takes your current branch and deploys it to Heroku
 
 > A live example can be found [here](https://github.com/the-hideout/stash/blob/3d8cd979d124bd13878c4bc92f74f3830cf53c22/.github/workflows/branch-deploy.yml)
@@ -231,7 +231,7 @@ jobs:
 
 This example shows how you could use this Action with [Railway](https://railway.app)
 
-- `.deploy noop` has no effect here (but you could change that)
+- `.noop` has no effect here (but you could change that)
 - `.deploy` takes your current branch and deploys it to Railway
 
 > A live example can be found [here](https://github.com/the-hideout/stash/blob/57d85e2092866b675a73ff23203c04962df12385/.github/workflows/branch-deploy.yml)
@@ -288,7 +288,7 @@ This example shows how you could use this Action with SSH
 
 You can define any commands you want to be run in your SSH Action and they would be gated by the branch-deploy Action.
 
-- `.deploy noop` has no effect here (but you could change that)
+- `.noop` has no effect here (but you could change that)
 - `.deploy` runs the SSH action with your branch
 
 > A live example can be found [here](https://github.com/the-hideout/cache/blob/c7dc4fa550f137efebf0ee656413985afba66770/.github/workflows/branch-deploy.yml)

docs/locks.md

@@ -35,7 +35,7 @@ Deployment locks in relation to environments also come in two flavors:
 Let's review the core concepts of deployment locks in a short summary:
 
 - Deployment locks are used to prevent multiple deployments from running at the same time and breaking things
-- Non-sticky locks are created automatically when running `.deploy` or `.deploy noop`
+- Non-sticky locks are created automatically when running `.deploy` or `.noop`
 - Sticky locks are created manually by commenting `.lock` on a pull request - They will persist until you remove them with `.unlock`
 - Locks are associated to a user's GitHub handle - This user can deploy any pull request in the repository and as many times as they want
 - Any user can remove a lock by commenting `.unlock` on any pull request in the repository

docs/usage.md

@@ -15,10 +15,11 @@ To view your available commands, environment targets, and how your workflow is s
 Deployments respect your repository's branch protection settings. You can trigger either a regular or noop deployment:
 
 - `.deploy` - Triggers a regular deployment using the default environment (think "Terraform apply" for example)
-- `.deploy noop` - Triggers a noop deployment (think "Terraform plan" for example)
+- `.noop` - Triggers a noop deployment (think "Terraform plan" for example)
 - `.deploy <environment>` - Triggers a deployment for the specified environment
-- `.deploy noop <environment>` - Triggers a noop deployment for the specified environment
+- `.noop <environment>` - Triggers a noop deployment for the specified environment
 - `.deploy <stable_branch>` - Trigger a rollback deploy to your stable branch (main, master, etc)
+- `.noop <stable_branch>` - Trigger a rollback noop to your stable branch (main, master, etc)
 
 ## Deployment Locks 🔒
 
@@ -47,6 +48,8 @@ If something goes wrong and you need to redeploy the main/master/base branch of
 
 - `.deploy main` - Rolls back to the `main` branch in production
 - `.deploy main to <environment>` - Rolls back to the `main` branch in the specified environment
+- `.noop main` - Rolls back to the `main` branch in production as a noop deploy
+- `.noop main to <environment>` - Rolls back to the `main` branch in the specified environment as a noop deploy
 
 > Note: The `stable_branch` option can be configured in your branch-deploy workflow definition. By default it is the `main` branch but it can be changed to `master` or any other branch name.
 
@@ -79,7 +82,7 @@ An example workflow for using this Action might look like this:
 4. Once CI is passing and the user has the proper reviews on their pull request, they can continue
 5. The user grabs the deployment lock as they need an hour or two for validating their change -> `.lock`
 6. The lock is claimed and now only the user who claimed it can deploy
-7. The user runs `.deploy noop` to get a preview of their changes
+7. The user runs `.noop` to get a preview of their changes
 8. All looks good so the user runs `.deploy` and ships their code to production from their branch
 
     > If anything goes wrong, the user can run `.deploy main` to rollback to the `main` branch