Fast, portable and reliable dependency analysis for any codebase. Supports license & vulnerability scanning for large monoliths. Language-agnostic; integrates with 20+ build systems.
When a user has configured a project to be linked to a binary via MSB, and then they lose access to the project (either because a different user is running the scan, or the project has been deleted, or some other reason) the scan currently fails:
Failed to resolve dependencies for the following FOSSA projects:
custom+19518/some-project$some-revision
You may not have access to the projects, or they may not exist (see the warnings below for details).
If desired you can use --experimental-skip-vsi-graph to skip resolving the dependencies of these projects.
The user then has to use --experimental-skip-vsi-graph to resolve this issue.
This PR alters the error to be a warning instead of a fatal error.
The --experimental-skip-vsi-graph flag is still there so that users using it don't encounter problems, but it is now largely irrelevant (it would only suppress this warning).
Acceptance criteria
This error is now a warning.
Testing plan
This is proven in the type system, I don't believe it requires testing.
No tests currently exist for this functionality, so I didn't alter any existing tests.
[x] I added tests for this PR's change (or explained in the PR description why tests don't make sense).
[x] If this PR introduced a user-visible change, I added documentation into docs/.
[x] If this PR added docs, I added links as appropriate to the user manual's ToC in docs/README.ms and gave consideration to how discoverable or not my documentation is.
[x] If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
[x] If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json AND I have updated example files used by fossa init command. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).
[x] If I made changes to a subcommand's options, I updated docs/references/subcommands/<subcommand>.md.
Overview
When a user has configured a project to be linked to a binary via MSB, and then they lose access to the project (either because a different user is running the scan, or the project has been deleted, or some other reason) the scan currently fails:
The user then has to use
--experimental-skip-vsi-graphto resolve this issue. This PR alters the error to be a warning instead of a fatal error.The
--experimental-skip-vsi-graphflag is still there so that users using it don't encounter problems, but it is now largely irrelevant (it would only suppress this warning).Acceptance criteria
This error is now a warning.
Testing plan
This is proven in the type system, I don't believe it requires testing. No tests currently exist for this functionality, so I didn't alter any existing tests.
Risks
No risk.
Metrics
None
References
https://fossa.atlassian.net/browse/ANE-2005
Checklist
docs/.docs/README.msand gave consideration to how discoverable or not my documentation is.Changelog.md. If this PR did not mark a release, I added my changes into an# Unreleasedsection at the top..fossa.ymlorfossa-deps.{json.yml}, I updateddocs/references/files/*.schema.jsonAND I have updated example files used byfossa initcommand. You may also need to update these if you have added/removed new dependency type (e.g.pip) or analysis target type (e.g.poetry).docs/references/subcommands/<subcommand>.md.