Add cargo deny configuration #64
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Adds the cargo-deny configuration file for the project. It allows to check for license compatibilities of the project and its dependencies, as well as other checks, one of the most important ones of which is the check for the binaries.
Adds the use of cargo-deny to automatically catch any issues before even building the crate(s).
MeirShpilraien
approved these changes
Oct 12, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This allows us to catch the license incompatibilities among our projects and all the dependencies and to catch accidental binaries within our source code.
To enable this, the
cargo deny(a cargo subcommand) is used. It parses theCargo.tomlfiles of each of the crates within the workspace and all the dependencies used by those crates, creating a single dependency graph. While building the graph, it also gathers information about licenses, the source code, and all the properties of those paths. This allows the utility to check for license compatibility and for the binaries included in any dependent crate. For example, it will trigger on the serde version 1.0.172 and till the version where the binary of serde_derive is removed. It will be triggered again once it happens. Current filters are setup only to ignore the crates that simply don't make sense without having binaries. Most of those are used within the test code, so they can safely be ignored. Examples:windows,winapiandlibloadingcrates.