Fast, portable and reliable dependency analysis for any codebase. Supports license & vulnerability scanning for large monoliths. Language-agnostic; integrates with 20+ build systems.
Reachability analysis is quite noisy, and many customers don't have it enabled for their organization anyways. This PR changes it so that:
Reachability analysis is skipped when the organization doesn't have reachability enabled. This means that "reachability not supported" messages as well as the entire reachability summary isn't printed out.
For an organization that does have it enabled, the messages will be the same. These are noisy, but we can refine them a bit in the future.
It still outputs a single message about reachability being turned off at the end of analysis regardless of whether reachability is enabled or not.
It will still try to do analysis and print out the analysis log messages with the -o option. We have no way of knowing if reachability is enabled in that case so it defaults to doing it.
Acceptance criteria
The output isn't nearly as noisy.
Testing plan
I tested by analyzing projects while having reachability analysis enabled or disabled in my organization.
Risks
None.
Metrics
Is this change something that can or should be tracked? If so, can we do it today? And how? If its easy, do it
[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
Reachability analysis is quite noisy, and many customers don't have it enabled for their organization anyways. This PR changes it so that:
-ooption. We have no way of knowing if reachability is enabled in that case so it defaults to doing it.Acceptance criteria
The output isn't nearly as noisy.
Testing plan
I tested by analyzing projects while having reachability analysis enabled or disabled in my organization.
Risks
None.
Metrics
Is this change something that can or should be tracked? If so, can we do it today? And how? If its easy, do it
References
ANE-1808
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.