noop prefix enhancements

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 📥
 
@@ -257,7 +257,7 @@ As seen above, we have two steps. One for a noop deploy, and one for a regular d
 | `status` | `true` | `${{ job.status }}` | The status of the GitHub Actions - For use in the post run workflow - Provided for you by default! |
 | `reaction` | `false` | `eyes` | If set, the specified emoji "reaction" is put on the comment to indicate that the trigger was detected. For example, "rocket" or "eyes" |
 | `trigger` | `false` | `.deploy` | The string to look for in comments as an IssueOps trigger. Example: ".deploy" |
-| `noop_trigger` | `false` | `noop` | The string to look for in comments as an IssueOps noop trigger. Example: "noop" - The usage would then be ".deploy noop" |
+| `noop_trigger` | `false` | `.noop` | The string to look for in comments as an IssueOps noop trigger. Example: ".noop" - The usage would then be ".noop" |
 | `lock_trigger` | `false` | `.lock` | The string to look for in comments as an IssueOps lock trigger. Used for locking branch deployments on a specific branch. Example: ".lock" |
 | `unlock_trigger` | `false` | `.unlock` | The string to look for in comments as an IssueOps unlock trigger. Used for unlocking branch deployments. Example: ".unlock" |
 | `help_trigger` | `false` | `.help` | The string to look for in comments as an IssueOps help trigger. Example: ".help" |
@@ -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")

__tests__/functions/deprecated-checks.test.js

@@ -0,0 +1,57 @@
+import {isDeprecated} from '../../src/functions/deprecated-checks'
+import * as core from '@actions/core'
+
+const docsLink =
+  'https://github.com/github/branch-deploy/blob/main/docs/deprecated.md'
+const warningMock = jest.spyOn(core, 'warning')
+
+var context
+var octokit
+
+beforeEach(() => {
+  jest.clearAllMocks()
+  jest.spyOn(core, 'warning').mockImplementation(() => {})
+
+  context = {
+    repo: {
+      owner: 'corp',
+      repo: 'test'
+    },
+    issue: {
+      number: 1
+    },
+    payload: {
+      comment: {
+        id: '1'
+      }
+    }
+  }
+
+  octokit = {
+    rest: {
+      reactions: {
+        createForIssueComment: jest.fn().mockReturnValueOnce({
+          data: {}
+        })
+      },
+      issues: {
+        createComment: jest.fn().mockReturnValueOnce({
+          data: {}
+        })
+      }
+    }
+  }
+})
+
+test('checks a deployment message and does not find anything that is deprecated', async () => {
+  const body = '.deploy to production'
+  expect(await isDeprecated(body, context, octokit)).toBe(false)
+})
+
+test('checks a deployment message and finds the old "noop" style command which is now deprecated', async () => {
+  const body = '.deploy noop'
+  expect(await isDeprecated(body, context, octokit)).toBe(true)
+  expect(warningMock).toHaveBeenCalledWith(
+    `'.deploy noop' is deprecated. Please view the docs for more information: ${docsLink}#deploy-noop`
+  )
+})