1## Description
2
3A few sentences describing the overall goals of the pull request's commits.
4
5## Related Issues
6
7List related issues.
8
9## Testing
10
11A few sentences describing what testing you've done, e.g., manual tests, automated tests, deployed in production, etc.
12
13## Checklist
14
15<!--
16 Please review the requirements for each checkbox, and check them
17 off (change "[ ]" to "[x]") as you verify that they are complete.
18-->
19- [ ] **Does my change need to be backported to a previous release?**
20 - What backport versions were discussed with the Maintainers in the Issue?
21
22- [ ] **I made sure to update `CHANGELOG.md`.**
23
24 Remember, the CHANGELOG needs to mention:
25 - Any new features
26 - Any changes to our included version of Envoy
27 - Any non-backward-compatible changes
28 - Any deprecations
29
30- [ ] **This is unlikely to impact how Ambassador performs at scale.**
31
32 Remember, things that might have an impact at scale include:
33 - Any significant changes in memory use that might require adjusting the memory limits
34 - Any significant changes in CPU use that might require adjusting the CPU limits
35 - Anything that might change how many replicas users should use
36 - Changes that impact data-plane latency/scalability
37
38- [ ] **My change is adequately tested.**
39
40 Remember when considering testing:
41 - Your change needs to be specifically covered by tests.
42 - Tests need to cover all the states where your change is relevant: for example, if you add a behavior that can be enabled or disabled, you'll need tests that cover the enabled case and tests that cover the disabled case. It's not sufficient just to test with the behavior enabled.
43 - You also need to make sure that the _entire area being changed_ has adequate test coverage.
44 - If existing tests don't actually cover the entire area being changed, add tests.
45 - This applies even for aspects of the area that you're not changing – check the test coverage, and improve it if needed!
46 - We should lean on the bulk of code being covered by unit tests, but...
47 - ... an end-to-end test should cover the integration points
48
49- [ ] **I updated `DEVELOPING.md` with any any special dev tricks I had to use to work on this code efficiently.**
50
51- [ ] **The changes in this PR have been reviewed for security concerns and adherence to security best practices.**
View as plain text