changelog checker#54
Conversation
|
🚨 Potential security issues detected. Learn more about Socket for GitHub ↗︎ To accept the risk, merge this PR and you will not be notified again.
Next stepsWhat is new author?A new npm collaborator published a version of the package for the first time. New collaborators are usually benign additions to a project, but do indicate a change to the security surface area of a package. Scrutinize new collaborator additions to packages because they now have the ability to publish code into your dependency tree. Packages should avoid frequent or unnecessary additions or changes to publishing rights. What is a deprecated package?The maintainer of the package marked it as deprecated. This could indicate that a single version should not be used, or that the package is no longer maintained and any new vulnerabilities will not be fixed. Research the state of the package and determine if there are non-deprecated versions that can be used, or if it should be replaced with a new, supported solution. Take a deeper look at the dependencyTake a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev. Remove the packageIf you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency. Mark a package as acceptable riskTo ignore an alert, reply with a comment starting with
|
|
|
||
| if (baseChanges === featureChanges) { | ||
| console.log( | ||
| "❌ No new entries detected under '## Unreleased'. Please update the changelog.", |
There was a problem hiding this comment.
Two suggestions related to this:
- This suggests that updating the changelog is the recommended way to address this error, but that's not necessarily true. We really don't want junk entries for non user-facing changes, that would make releases much more difficult rather than easier. We should be suggesting that the contributor either document user-facing changes, or add
no-changelogto bypass the check if there are no user-facing changes. - Have you considered putting this in a comment rather than the console output? It will be much easier to see this feedback if it's in a comment, particularly as we first roll out this workflow.
Co-authored-by: Norbert Elter <72046715+itsyoboieltr@users.noreply.github.com>
Co-authored-by: Norbert Elter <72046715+itsyoboieltr@users.noreply.github.com>
|
@Gudahtt @itsyoboieltr I’ve opened a PR in Core for this same workflow action: MetaMask/core#5575. |
I've made the code review updates and incorporated majority of the changes from your PR as it pertained to this one @Gudahtt @cryptodev-2s @itsyoboieltr @sethkfman if you could review one more |
6 participants
This Change introduces a new shared workflow that will be confused by metamask-mobile and metamask-extension.
It will enforce that incoming PRs have either a modification to the Unreleased Section of the README or a label on the PR ( no-changelog ) which will indicate theres no external facing changes users need to know about
https://github.com/MetaMask/MetaMask-planning/issues/3678