* adding cve finding and adding release-notes to PR template Signed-off-by: James Strong <strong.james.e@gmail.com> * update cve report with verbiage around open CVEs and not disclosures Signed-off-by: James Strong <strong.james.e@gmail.com> * fix then assignees Signed-off-by: James Strong <strong.james.e@gmail.com> Signed-off-by: James Strong <strong.james.e@gmail.com>
68 lines
2.8 KiB
Markdown
68 lines
2.8 KiB
Markdown
<!--- Provide a general summary of your changes in the Title above --->
|
|
<!--- Please don't @-mention people in PR or commit messages (do so in an additional comment). --->
|
|
|
|
## What this PR does / why we need it:
|
|
<!--- Why is this change required? What problem does it solve? -->
|
|
<!--- If it fixes an open issue, please link to the issue here. -->
|
|
|
|
## Types of changes
|
|
<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->
|
|
- [ ] Bug fix (non-breaking change which fixes an issue)
|
|
- [ ] New feature (non-breaking change which adds functionality)
|
|
- [ ] CVE Report (Scanner found CVE and adding report)
|
|
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
|
|
- [ ] Documentation only
|
|
|
|
## Which issue/s this PR fixes
|
|
<!--
|
|
(optional, in `fixes #<issue number>` format, will close that issue when PR gets merged):
|
|
|
|
fixes #
|
|
-->
|
|
|
|
## How Has This Been Tested?
|
|
<!--- Please describe in detail how you tested your changes. -->
|
|
<!--- Include details of your testing environment, and the tests you ran to -->
|
|
<!--- see how your change affects other areas of the code, etc. -->
|
|
|
|
## Checklist:
|
|
<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
|
|
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
|
|
- [ ] My change requires a change to the documentation.
|
|
- [ ] I have updated the documentation accordingly.
|
|
- [ ] I've read the [CONTRIBUTION](https://github.com/kubernetes/ingress-nginx/blob/main/CONTRIBUTING.md) guide
|
|
- [ ] I have added unit and/or e2e tests to cover my changes.
|
|
- [ ] All new and existing tests passed.
|
|
- [ ] Added Release Notes.
|
|
|
|
## Does my pull request need a release note?
|
|
Any user-visible or operator-visible change qualifies for a release note. This could be a:
|
|
|
|
- CLI change
|
|
- API change
|
|
- UI change
|
|
- configuration schema change
|
|
- behavioral change
|
|
- change in non-functional attributes such as efficiency or availability, availability of a new platform
|
|
- a warning about a deprecation
|
|
- fix of a previous Known Issue
|
|
- fix of a vulnerability (CVE)
|
|
|
|
No release notes are required for changes to the following:
|
|
|
|
- Tests
|
|
- Build infrastructure
|
|
- Fixes for unreleased bugs
|
|
|
|
For more tips on writing good release notes, check out the [Release Notes Handbook](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/release-notes)
|
|
|
|
<!--
|
|
If no, just write "NONE" in the release-note block below.
|
|
If yes, a release note is required:
|
|
Enter your extended release note in the block below. If the PR requires additional action from users switching to the new release, include the string "action required".
|
|
|
|
For more information on release notes see: https://git.k8s.io/community/contributors/guide/release-notes.md
|
|
-->
|
|
```release-note
|
|
PLACE RELEASE NOTES HERE
|
|
```
|