Ane 1028 broker fix fatal exit

[JeffreyHuynh1]

Overview

Broker fails fatally if FOSSA CLI doesn't find targets (Fixed in previous PR). We want Broker Fix to surface these errors.

Acceptance criteria

Broker does not fatally exit when scanning a project that does not have analysis targets.

Broker reports such errors during broker fix.

Note: this doesn’t mean “reports historical errors”; I mean “during broker fix Broker should download the integration and run fossa analyze -o on it, and report an error if that fails”.

Testing plan

1. Run Broker Fix on an empty repo. This should display the suggestions on how to debug the error (Broker doesn't fatally exit)
2. Unit Test: with_failing_http_no_auth_integration_scan() [tests/fix.rs]
   2.a Tests a failed scan
3. Unit Test: with_failing_http_no_auth_download_cli() [tests/fix.rs]
   3.a Tests failure on downloading fossa cli during attempt to scan integration

Risks

I created this function that propagates potential errors during scan.

check_integration_scan()

I created new variants of all the possible errors that could be encountered but didn't provide a 'fix' for all of them. Only for errors :
Error::DownloadFossaCli & Error::CheckIntegrationScan

I was unsure of the fixes for these errors:
Error::EmptyReferences & Error::CloneReference

Please let me know if this if is fine for now or if you want me to implement the fixes for these errors.

Would there ever be a case where a user would have empty references?

References

• ANE-1028

Checklist

• I added tests for this PR's change (or explained in the PR description why tests don't make sense).

[JeffreyHuynh1]

I changed the remote because the integration test: with_successful_http_no_auth_integration() in fix.rs wasn't working as intended.

I talked to scott and he told me that it is because broker removes PATH field when using fossa analyze through broker. The results from fossa analyze and broker would differ when running a scan on the repo: https://github.com/fossas/broker.git due to static analysis. Therefore I changed the remote that we are scanning.

[jssblck]

lgtm after the windows comment!

[jssblck]

I don't think this is how env vars are set for the current session in powershell. Please validate- if I'm wrong I'm happy to accept, but otherwise please fix it.

Also, I think I never mentioned before that when we say "windows" we mean "windows in powershell". Sorry about that.