|
1 | | -## Proposed Changes |
2 | | - |
3 | | -### Description |
4 | | - |
5 | | -Describe the proposed changes: |
6 | | - |
7 | | - - |
8 | | - |
9 | | -## PR Requirements |
10 | | - |
11 | | -Developers, verify you have completed the following items by checking them off: |
12 | | - |
13 | | -### Testing |
14 | | - |
15 | | -#### Unit Tests |
16 | | - |
17 | | -Review our documentation on [generating](https://docs.rapid7.com/insightconnect/unit-test-generation) and [writing](https://docs.rapid7.com/insightconnect/unit-test-primer) plugin unit tests |
18 | | - |
19 | | -- [ ] Unit tests written for any new or updated code |
20 | | - |
21 | | -#### In-Product Tests |
22 | | - |
23 | | -If you are an InsightConnect customer or have access to an InsightConnect instance, the following in-product tests should be done: |
24 | | - |
25 | | -- [ ] Screenshot of job output with the plugin changes |
26 | | -- [ ] Screenshot of the changed connection, actions, or triggers input within the InsightConnect workflow builder |
27 | | - |
28 | | -### Style |
29 | | - |
30 | | -Review the [style guide](https://docs.rapid7.com/insightconnect/style-guide/) |
31 | | - |
32 | | -- [ ] For dependencies, pin [OS package](https://docs.rapid7.com/insightconnect/style-guide/#dockerfile) and [Python package](https://docs.rapid7.com/insightconnect/style-guide/#requirements.txt) versions |
33 | | -- [ ] For security, set least privileged account with ``USER nobody`` in the ``Dockerfile`` when possible |
34 | | -- [ ] For size, use the [slim SDK images](https://docs.rapid7.com/insightconnect/sdk-guide/#sdk-guide) when possible: ``rapid7/insightconnect-python-3-38-slim-plugin:{sdk-version-num}`` and ``rapid7/insightconnect-python-3-38-plugin:{sdk-version-num}`` |
35 | | -- [ ] For error handling, use of [PluginException](https://docs.rapid7.com/insightconnect/error-handling-in-integrations/#plugin-exceptions) and [ConnectionTestException](https://docs.rapid7.com/insightconnect/error-handling-in-integrations#connection-exceptions) |
36 | | -- [ ] For logging, use [self.logger](https://docs.rapid7.com/insightconnect/sdk-guide/#logging) |
37 | | -- [ ] For docs, use [changelog style](https://docs.rapid7.com/insightconnect/style-guide/#changelog) |
38 | | -- [ ] For docs, validate markdown with ``insight-plugin validate`` which calls ``icon_validate`` to lint ``help.md`` |
39 | | - |
40 | | -### Functional Checklist |
41 | | -- [ ] Work fully completed |
42 | | -- [ ] Functional |
43 | | - - [ ] Any new actions/triggers include JSON [test files](https://docs.rapid7.com/insightconnect/style-guide/#tests) in the `tests/` directory created with `insight-plugin samples` |
44 | | - - [ ] Tests should all pass unless it's a negative test. Negative tests have a naming convention of `tests/$action_bad.json` |
45 | | - - [ ] Unsuccessful tests should fail by raising an exception causing the plugin to die and an object should be returned on successful test |
46 | | - - [ ] Add functioning test results to PR, sanitize any output if necessary |
47 | | - * Single action/trigger `insight-plugin run -T tests/example.json --debug --jq` |
48 | | - * All actions/triggers shortcut `insight-plugin run -T all --debug --jq` (use PR format at end) |
49 | | - - [ ] Add functioning run results to PR, sanitize any output if necessary |
50 | | - * Single action/trigger `insight-plugin run -R tests/example.json --debug --jq` |
51 | | - * All actions/triggers shortcut `insight-plugin run --debug --jq` (use PR format at end) |
52 | | - |
53 | | -### Assessment |
54 | | - |
55 | | -You must validate your work to reviewers: |
56 | | - |
57 | | -1. Run `insight-plugin validate` and make sure everything passes |
58 | | -2. Run the assessment tool: `insight-plugin run -A`. For single action validation: `insight-plugin run tests/{file}.json -A` |
59 | | -3. Copy (`insight-plugin ... | pbcopy`) and paste the output in **a new post** on this PR |
60 | | -4. Add required screenshots from the In-Product Tests section |
| 1 | +## 🎫 Ticket |
| 2 | +<!-- Link to the related Jira ticket (if applicable, typically for features and bug fixes) --> |
| 3 | +<!-- If no ticket exists, you can remove this section or write "N/A" --> |
| 4 | +<!-- Ticket: [<insert ticket title>](<insert ticket link>) --> |
| 5 | + |
| 6 | +## 🧩 Type of Change |
| 7 | +<!-- Choose the type of change --> |
| 8 | +- [ ] Feature |
| 9 | +- [ ] Bug fix |
| 10 | +- [ ] Other |
| 11 | + |
| 12 | +## 🧠 Background & Motivation |
| 13 | +<!-- Why is this change needed? What problem or context led to this PR? --> |
| 14 | +<!-- Provide a short explanation of the motivation and the problem being solved. --> |
| 15 | +<!-- Examples: |
| 16 | +- "Users reported X error when doing Y" |
| 17 | +- "New feature X was requested" |
| 18 | +--> |
| 19 | + |
| 20 | +## ✨ What Changed |
| 21 | +<!-- What was done? Summarize the key changes in this PR. --> |
| 22 | +<!-- Describe the core implementation and high-level impact. --> |
| 23 | +<!-- Examples: |
| 24 | +- "Added new action 'X' to plugin Y" |
| 25 | +- "Refactored X to improve performance" |
| 26 | +--> |
| 27 | + |
| 28 | +## 🧪 Testing |
| 29 | +<!-- Describe how you verified the changes work as intended --> |
| 30 | +<!-- Include details of your testing process, such as: |
| 31 | +- Unit tests |
| 32 | +- Manual testing steps |
| 33 | +- Any relevant screenshots or logs |
| 34 | +--> |
0 commit comments