Make it possible to trust some modules
There are cases where it makes sense to trust some modules.
For example, a company using a frequent release pace may want
to trust their company artifacts (changing often so painful
to update the configuration) more than the external dependencies.
This gives the opportunity to tell what are the trusted modules.
The configuration requires at least a group name, but modules
can be trusted on the whole (group, name, version, file name)
It is also possible to use regular expressions, for example one
09 Dec 19 c0cb9bee48a1ab46b05e802c1141d2e57e3f0d28
Add dependency verification mode
This commit introduces a selection of the dependency verification
mode. There are 3 different modes: strict (default), lenient and
The lenient mode has been added because dogfooding the feature showed
it could be painful to udpate the dependency verification
metadata file without such an option: often we want to diagnose
why a dependency is here, but as soon as the dependency
verification file is present, verification is active and immediately
fails the build.
This effectively prevents from using the usual tooling to check
where a dependency comes from. The workaround was to temporarily
rename the file, run the build, then rename again, which was tedious.
So, instead of adding a mode where verification would be totally
ignored, this commit introduces a mode where the errors are turned
into warnings. This doesn't totally silence the problems, which
makes them more visible to the developer.
The "off" mode is for use cases where users prefer not to deal
with upgrades locally, but want to see verification happening
on CI only.
27 Nov 19 e32ee77689f0e76888480adf55a66b31ee4e7cc3