Add an option to deny packages or groups of packages

[adrienpessu]

TL;DR;

The goal is to check if someone is adding specific packages or group of packages in the codebase that isn't supposed to be added.

Context

GitHub customers want to deny access to certain dependencies base on a wide range of criteria other than vulnerabilities and licences.
Some examples of criteria :

• The project isn't maintained any more
• We don't want to depend on our competitor's open source libraries
• We don't want any dependencies of a particular ecosystem because it has a bad reputation (security wise), it depends on an entity based in a country we need to avoid for legal reasons, ...

Since those criteria are wide, the simplest way is to deny based on the name or the group of the packages.

Actions

• Add option for a list of denied packages
• Add option for a list of denied groups of packages
• Add a specific message into the summary
• check the denied lists and failed if found
• Add tests
• Edit Readme

[febuiles]

@adrienpessu would you mind adding a bit more context to the PR description? What motivates this change and why was it solved this way?

[adrienpessu]

@febuiles Context updated in the description 👍

[febuiles]

@adrienpessu thank you for the additional information! From a code POV this looks fine, some things that would be appreciated before merging and releasing a new version:

• Add an example configuration to: https://github.com/actions/dependency-review-action/blob/main/docs/examples.md and then link to it from the README changes. This helps us educate users and create release notes.
• Create a public repository that uses this action and link to a public run of the Action pointing to your branch (i.e. link to a run of your changes). Example: https://github.com/future-funk/expert-octo-garbanzo/actions/runs/5397412934/job/14612005965?pr=2. This helps us make sure that the code has been tested end to end.

Once these two are done I'll cut the new release.

[adrienpessu]

@febuiles I have added the example and I prepared the testing repo : https://github.com/adrienpessu/sample-dependency-review-deny-packages/actions/runs/5794591201?pr=1, I can link it as is, but it uses my forked action. Once merge, I will be able to change it to the real action.
Second question, where do I put the link to the run so people can find it, I didn't see other links in the current repo

[febuiles]

@adrienpessu Sorry for the confusion, the test run is for us devs to leave a record here of a successful run of the changes since we don't have proper E2E tests in Actions. We don't need to share it as part of the documentation.

Thanks for the new examples, they point out a change we need to make: We should use PURLs instead of package names. It avoids conflicts for multiple dependencies with the same name but different ecosystems (think of a library called json that exists in both your Gemfile and your package.json). Apologies for not calling out this earlier, I thought we were already using PURLs.

[adrienpessu]

@febuiles while I like the flexibility of not having to specify the build system, I understand the need to avoid confusion.
I made the change and here is an example : https://github.com/adrienpessu/sample-dependency-review-deny-packages/actions/runs/5798862598?pr=1

[febuiles]

@adrienpessu I've merged the changes with some tweaks to the docs. I expect to do a release later today/tomorrow. Thank you very much!

[adrienpessu]

Great thank you

[febuiles]

By merging I forgot that the README changes would be public instantly, so I decided to cut the new release now. Changes are available starting with 3.0.7. Thanks again!