License scanning fails silently when npm list has unmet peer dependencies
Summary
When an npm package-lock.json contains unmet peer dependencies, the license scanning fails for that file, but the license-scanning autodevops job "succeeds".
Steps to reproduce
- create a package.json and package-lock.json file containing an unmet peer dependency
include:
- template: License-Scanning.gitlab-ci.ymlWhat is the current bug behavior?
- The output of
npm list --long --json --productionis printed to the gitlab job log. (For our project, this output exceeds the allowed length of a log, which means we couldn't see the end of the output, which is the part which would have explained the problem) - The job continues as if there were no packages found, so it appears to succeed but no packages appear in the license report
What is the expected correct behavior?
Either: the job should fail, so the user knows there is a problem
Or: the job should print a warning about the unmet peer dependencies, and continue to analyse the licenses for the rest of the installed packages. (This is the behaviour of the LicenseFinder gem, which is taken out by the license-finder image's monkeypatches).
Output of checks
This bug happens on GitLab.com
Possible fixes
When there are unmet peer dependencies, the LicenseFinder gem attempts to continue: https://github.com/pivotal/LicenseFinder/blob/master/lib/license_finder/package_managers/npm.rb#L39
The license-finder image monkeypatches this class. It ignores the error and returns an empty hash here: https://gitlab.com/gitlab-org/security-products/analyzers/license-finder/-/blob/main/lib/license/finder/ext/npm.rb#L37
Implementation plan
- in https://gitlab.com/gitlab-org/security-products/analyzers/license-finder/-/blob/main/lib/license/finder/ext/npm.rb#L37 add check for
status.exitstatus = 1(status for unmet peer dependencies), continue parsing in case of this positive condition. - Add tests to check this condition
- Create a report with unmet peer dependencies to test on it the fix.